At the last Google IO Conference, Google made a rather ambiguous announcement about their partnership with Samsung and watches. Samsung currently sells their Gear watches running an operating system that they made in collaboration with a few other companies. In the announcement, Google said that they were combining their Wear OS operating system with Samsung’s Tizen operating system. What exactly does this mean? There was not clarification given during the conference. Looking at the conference sessions, there were two sessions on development for Google’s Android OS.
Generally speaking, one can’t just combine two operating systems. They could build a different operating system that has support for the applications from another OS or take designs from the UI of an OS and apply it to another. But there isn’t anything meaningful in the phrase “Combine operating system.” Jumping over to the Samsung Developer forums, I found there were people with similar questions, all of which were met with the reply “We can’t give you more information at this time.”
Information was finally made available earlier this week. In summary, Samsung is going to adopt Wear OS (Android) for their watches. They said that they will support the existing Tizen based watches for another three years. That announcement was surprisingly more direct than I’ve seen Samsung be with other products that they sunset. What I’ve usually seen is that new versions of a product stop coming without any announcement being made (Their Tizen based Z phones, the Gear 360, and Gear VR headsets are all examples of products for which this happened).
If you would like to see the announcement yourself, you can view it in the YouTube video below. The part of interest can be found at time marker 11:25 and continues to the announcement of 3 years of Tizen support at time marker 16:38. What exactly is meant by “support” could still get more clarification. I expect this to at least mean that developers will be able to submit and update applications for the next few years, but Samsung will be giving significantly less resources to Tizen wearable.
This leaves Samsung’s TVs as their last category of hardware that uses the Tizen operating system.
Among my many gadgets I have a Faraday Bag. Faraday bags are essentially a flexible version of a faraday cage. Such devices contain metalic content and prevent the passage of radio signals. You have probably seen various applications of this, such as wallets or envelops designed to prevent an NFC credit card from being read, or the metalic grid in the door of a Microwave oven that prevents the microwave radiation from getting out.
I won’t get into the physics of how these work. But it is worth noting that a Faraday cage may only work for a range frequencies. A cage that prevents one device from getting a signal might not have the same effect on another that uses a different frequency. While I’ve seen that my Faraday Bag has successfully blocked WiFi and cellular signals from reaching my phone and tablet, I wanted to see if it would work with an AirTag. For those unfamiliar, the AirTag is Apple’s implementation of a Bluetooth tracking device. Another well known Bluetooth tracker is from Tile. The fundamentals of how these devices work is essentially the same.
The trackers are low-energy Bluetooth devices. If the tracker is near your phone, the phone detects the signal and the ID unique to the tracker. The phone takes notice where it was located when it looses signal to the tracker and generally assumes that the tracker is in the last place that it was when it received a signal. That isn’t always the case. The tracker my have been moved after the phone lost the signal (think of a device left in a taxi). The next method of locating that these devices use is that other people’s phones may see the tracker and relay the position. For the Tile devices anyone else that has the Tile app on their phone effectively participates in relaying the position of tiles that they encounter. For the AirTag anyone with a fairly recent iPhone and Firmware participates. My expectation is that that the ubiquity of the iPhone will make it the location network with more coverage. As a test, I gave an AirTag to a wiling participant and asked that they keep the device for a day. When I checked in on the location of the Device using the “Find My” app on the iPhone, I could see the person’s movements. On a commute to work, other iPhones that the person drove by on the Interstate reported the position. I could see the person’s location within a few minutes of them arriving at work.
There are some obvious privacy concerns with these devices. Primarily from an unwilling party having an AirTag put in their belongings. Apple is working on some solutions for some of the security concerns, though others remain. I thought about someone transporting a device with an AirTag that may not want their location located. One way to do this is to remove the battery. Another is to block the signal. Since I already have a Faraday Bag I decided to test out this second method.
I found that my Faraday Bag successfully blocks the AirTag from being detected or from receiving a signal. You can see the test in the above video. This addresses one of the concern for such trackers, though not all of them. This is great for an AirTag that one is knowingly transporting. For one that a person doesn’t realize is in their belongings, a method of detection is needed. For iPhone users, the iPhone is reported to alert a user if there is an AirTag that stays within their proximity that is not their own. Results from others testing this have been a bit mixed. The AirTags are also reportedly going to play an alert sound if they arenot within range of their owner for some random interval between 8 and 24 hours.
Presently, Android users would not get a warning. Though Apple is said to be working on an application for Android for detecting lingering AirTags. In the absence of such an application, I’ve tried using Bluetooth scanners on Android. The Airtag is successfully detected. The vendor (Apple) can be retrieved from the AirTag, but no other information is retrievable. I’ve got some ideas on how to specifically identify an AirTag within code for Android, but need to do more testing to validate this. This is something that I plan to return to later on.
I purchased this Faraday Bag some time ago. The specific bag that I have is, from what I have found, no longer available. But other comparable bags are available on Amazon.
Posts may contain products with affiliate links. When you make purchases using these links, we receive a small commission at no extra cost to you. Thank you for your support.
Many apps require a network connection. Provided the connection meets bandwidth requirements, the apps don’t typically care how that connection is established. But for applications that engage in controlling home devices the application may specifically want to communicate over WiFi. In Android there are two ways that this has been handled. Some applications will turn on WiFi if it is turned off. Others may prompt the user to turn on WiFi.
Of the two options, the application turning on WiFi is an approach that is not supported on Android Q and later. This is part of the privacy changes in Android Q. For older versions of Android, controlling the WiFi could be performed though the WIFI_SERVICE.
val wifi = getSystemService(WIFI_SERVICE) as WifiManager
if(!wifi.isWifiEnabled)
wifi.isWifiEnabled = true;
If you try this now, Android Studio will give a deprecation warning. To have the user change the WiFi state the application can open the WiFi control interface for the user. Rather than dump the user into the WiFi control interface, it is generally better to prompt them first. The WiFi control UI can be opened with an intent for ACTION_WIRELESS_SETTINGS.
An easy way to prompt the user is to use the AlertDialogBuilder. A complete solution looks like the following.
fun checkWifiState() {
val wifi = getSystemService(WIFI_SERVICE) as WifiManager
if(!wifi.isWifiEnabled) {
val dialogClickListener =
DialogInterface.OnClickListener { dialog, which ->
when (which) {
DialogInterface.BUTTON_POSITIVE -> {
startActivity(Intent(Settings.ACTION_WIRELESS_SETTINGS));
}
DialogInterface.BUTTON_NEGATIVE -> {
}
}
}
var builder:AlertDialog.Builder = AlertDialog.Builder(this) as AlertDialog.Builder
builder.setMessage("WiFi must be enabled. Do you want to open the WiFi controls?")
.setPositiveButton("Yes", dialogClickListener)
.setNegativeButton("No", dialogClickListener)
.show()
}
}
j2i.net 