Here's a first look at the setup process for Android's Find My Device network!
1) You'll get a notification asking you to "add this device to the Find My Device network"
2) You'll see an intro screen explaining how Find My Device can use the network "of over a billion Android devices" to store your devices' recent locations to help you locate your offline devices and accessories. Android devices in the network detect nearby items using Bluetooth.
By default, the network is used to locate devices in "high-traffic areas" only, which means location info sent by your device is only used "if others on the network also detect the item."
Device locations are encrypted using the lock screen of your Android devices and can only be seen by you and those you share your devices with in Find My Device.
3) You'll see a page asking you to enter the lock screen for another device that's already added to the network. In this case, I was asked to enter the PIN of my Pixel 6a whereas I was trying to opt in on my Pixel 7 Pro.
4) You're all set at this step, but you can go to settings to change how your device is located.
I don't have screenshots of the Find My Device network settings themselves, but @nailsad_eleos shared them earlier, so I also attached that to this post.
The Find My Device network hasn't rolled out yet, so it's possible this setup process could change before it does.
I'm most curious to see whether Find My Device network will remain opt-in or whether it'll be opt-out when it launches. If it's opt-in and requires the user accepting/seeing this notification, then I can imagine many people won't enable it.
However, if Google adds/mandates a toggle to be added to the setup wizards of Android devices that says something like "find your Android device when it's offline", and this toggle opts the device into the Find My Device network, then I can see this feature getting turned on a lot more. I believe that's how Apple does it as well.
1) You'll get a notification asking you to "add this device to the Find My Device network"
2) You'll see an intro screen explaining how Find My Device can use the network "of over a billion Android devices" to store your devices' recent locations to help you locate your offline devices and accessories. Android devices in the network detect nearby items using Bluetooth.
By default, the network is used to locate devices in "high-traffic areas" only, which means location info sent by your device is only used "if others on the network also detect the item."
Device locations are encrypted using the lock screen of your Android devices and can only be seen by you and those you share your devices with in Find My Device.
3) You'll see a page asking you to enter the lock screen for another device that's already added to the network. In this case, I was asked to enter the PIN of my Pixel 6a whereas I was trying to opt in on my Pixel 7 Pro.
4) You're all set at this step, but you can go to settings to change how your device is located.
I don't have screenshots of the Find My Device network settings themselves, but @nailsad_eleos shared them earlier, so I also attached that to this post.
The Find My Device network hasn't rolled out yet, so it's possible this setup process could change before it does.
I'm most curious to see whether Find My Device network will remain opt-in or whether it'll be opt-out when it launches. If it's opt-in and requires the user accepting/seeing this notification, then I can imagine many people won't enable it.
However, if Google adds/mandates a toggle to be added to the setup wizards of Android devices that says something like "find your Android device when it's offline", and this toggle opts the device into the Find My Device network, then I can see this feature getting turned on a lot more. I believe that's how Apple does it as well.
🔥41👍11❤4
Media is too big
VIEW IN TELEGRAM
This app uses AirDrop to send files from your Android phone to your Macbook!
Yes, it actually uses AirDrop. That means you don't have to install ANYTHING on your Mac to send files from your Android phone!
Here's a video of a Galaxy Z Flip 5 AirDropping a file to a Macbook running macOS Ventura 13.5.1.
(Thanks to u/FragmentedChicken for testing this app for me and sharing the video!)
A few months ago, Twitter user Linus13499209 brought an app called WarpShare to my attention. WarpShare is an app made by the developers of MoKee, an AOSP-based custom ROM that was popular in China. Since MoKee wasn't as popular outside of China, it seems the existence of their WarpShare app slipped under the radar.
I was skeptical about whether it would work at all. Grishka, the developer of NearDrop, an open source port of Google's Nearby Share to macOS, told me that they were under the assumption that AirDrop requires the use of AWDL (Apple Wireless Direct Link, Apple's proprietary WiFi-based protocol) to communicate both ways.
However, it seems that AWDL is only required for your Android phone to be discoverable by your Mac (ie. to send files from your Mac to your Android phone) but not the other way around. Because of this, though, WarpShare only supports sending files from Android to Mac but not vice versa.
Your Mac also needs to have AirDrop discoverability set to "everyone" for this to work, as "contacts-only" requires Apple-signed certificates. Plus, it also doesn't support sending files from Android to iPhones or iPads, even when "everyone" mode is enabled.
Still, if you find other Android --> Mac file sharing options to be lackluster, give WarpShare a try! The fact that it works at all is incredible, which is why I'm sharing this news here.
If you want to download WarpShare on your Android device, you'll need to compile the app from its source code. If you're a Patron/X subscriber, however, I will share my compiled APK with you.
Yes, it actually uses AirDrop. That means you don't have to install ANYTHING on your Mac to send files from your Android phone!
Here's a video of a Galaxy Z Flip 5 AirDropping a file to a Macbook running macOS Ventura 13.5.1.
(Thanks to u/FragmentedChicken for testing this app for me and sharing the video!)
A few months ago, Twitter user Linus13499209 brought an app called WarpShare to my attention. WarpShare is an app made by the developers of MoKee, an AOSP-based custom ROM that was popular in China. Since MoKee wasn't as popular outside of China, it seems the existence of their WarpShare app slipped under the radar.
I was skeptical about whether it would work at all. Grishka, the developer of NearDrop, an open source port of Google's Nearby Share to macOS, told me that they were under the assumption that AirDrop requires the use of AWDL (Apple Wireless Direct Link, Apple's proprietary WiFi-based protocol) to communicate both ways.
However, it seems that AWDL is only required for your Android phone to be discoverable by your Mac (ie. to send files from your Mac to your Android phone) but not the other way around. Because of this, though, WarpShare only supports sending files from Android to Mac but not vice versa.
Your Mac also needs to have AirDrop discoverability set to "everyone" for this to work, as "contacts-only" requires Apple-signed certificates. Plus, it also doesn't support sending files from Android to iPhones or iPads, even when "everyone" mode is enabled.
Still, if you find other Android --> Mac file sharing options to be lackluster, give WarpShare a try! The fact that it works at all is incredible, which is why I'm sharing this news here.
If you want to download WarpShare on your Android device, you'll need to compile the app from its source code. If you're a Patron/X subscriber, however, I will share my compiled APK with you.
🔥40😱10👍8❤2👏2
Google is starting to migrate users from the Play Store version of the Health Connect app to the system one that's built into Android 14.
Recently, users on Android 14 who use health and fitness apps that sync with Health Connect have been getting notices (like the one shown above) that "the Health Connect (Beta) app is being integrated with the Android system" and that "[app] needs to be updated to continue syncing with Health Connect."
A few users trying to set up the WHOOP app to use Health Connect have received this notice, but since that app hasn't been updated yet to support the new system version of Health Connect, users aren't able to grant the app permission to read/write data to Health Connect.
Once Whoop issues an update (and other apps affected by this), this problem should go away. Also, after completing the data migration, you should be able to disable the Play Store version of Health Connect.
More info on the Health Connect migration plan.
Recently, users on Android 14 who use health and fitness apps that sync with Health Connect have been getting notices (like the one shown above) that "the Health Connect (Beta) app is being integrated with the Android system" and that "[app] needs to be updated to continue syncing with Health Connect."
A few users trying to set up the WHOOP app to use Health Connect have received this notice, but since that app hasn't been updated yet to support the new system version of Health Connect, users aren't able to grant the app permission to read/write data to Health Connect.
Once Whoop issues an update (and other apps affected by this), this problem should go away. Also, after completing the data migration, you should be able to disable the Play Store version of Health Connect.
More info on the Health Connect migration plan.
👍20👀14🤔5❤3🥱2🤡1
Shown above is one half of what Google is bringing to Android phones: device-to-device eSIM profile transfers through QR code scanning.
You'll also be able to "convert" a pSIM into an eSIM, but this will require carrier backend support (starting with T-Mobile/Deutsche Telekom). Converting a pSIM to an eSIM might involve permanently disabling the pSIM after the transfer is done, from what I hear.
H/T AssembleDebug for the initial discovery of this activity.
(The above screenshots come from the EsimTransferSourceActivity and EsimTransferHalfSheetActivity activities within Google Play Services. However, the actual eSIM transfer process likely won't work unless we get an updated version of the SIM Manager app on Pixel.)
You'll also be able to "convert" a pSIM into an eSIM, but this will require carrier backend support (starting with T-Mobile/Deutsche Telekom). Converting a pSIM to an eSIM might involve permanently disabling the pSIM after the transfer is done, from what I hear.
H/T AssembleDebug for the initial discovery of this activity.
(The above screenshots come from the EsimTransferSourceActivity and EsimTransferHalfSheetActivity activities within Google Play Services. However, the actual eSIM transfer process likely won't work unless we get an updated version of the SIM Manager app on Pixel.)
👍34❤13🔥3
A few days after Galaxy Unpacked, I got to visit Samsung's "Smart City" in Korea. I saw a bunch of REALLY cool stuff there (and of course, learned a lot!)
Although I wasn't able to take many photos, I did jot down a ton of notes. You can read about my experience here.
I'm not super well-versed in the hardware manufacturing/assembly side of mobile tech, so I apologize if the technical details on what I saw there are a bit light! Still, there's a lot of smaller details about Samsung's manufacturing/assembly lines that you might not have seen reported elsewhere before!
Also, from what I can tell, Samsung didn't take a lot of media to their "Smart City" tour in Gumi. Most media I know who went to Unpacked instead saw Samsung's "Digital City" AKA their HQ, which was less on the industrial side of things. So this was a rare opportunity to see the campus (seriously, look at how outdated the photos are on Google!)
(Funny anecdote from the tour: Samsung is basically pretending the Galaxy Note 7 never existed. It wasn't shown in their smartphone museum nor was it shown in any wall art/graphics that showed the timeline of their flagship phone releases, lmao. Makes sense why, but still amusing to note.)
I did at least get to see all their special edition Olympic branded devices + the abandoned Bixby-powered Galaxy Home speaker!
Although I wasn't able to take many photos, I did jot down a ton of notes. You can read about my experience here.
I'm not super well-versed in the hardware manufacturing/assembly side of mobile tech, so I apologize if the technical details on what I saw there are a bit light! Still, there's a lot of smaller details about Samsung's manufacturing/assembly lines that you might not have seen reported elsewhere before!
Also, from what I can tell, Samsung didn't take a lot of media to their "Smart City" tour in Gumi. Most media I know who went to Unpacked instead saw Samsung's "Digital City" AKA their HQ, which was less on the industrial side of things. So this was a rare opportunity to see the campus (seriously, look at how outdated the photos are on Google!)
(Funny anecdote from the tour: Samsung is basically pretending the Galaxy Note 7 never existed. It wasn't shown in their smartphone museum nor was it shown in any wall art/graphics that showed the timeline of their flagship phone releases, lmao. Makes sense why, but still amusing to note.)
I did at least get to see all their special edition Olympic branded devices + the abandoned Bixby-powered Galaxy Home speaker!
👍26❤7😁1
Here's a summary of recent and upcoming changes in ART (Android Runtime).
ART provides the runtime and core APIs that "all apps and most OS services rely on." As Google explains, both Java and Kotlin code are compiled down to bytecode that's executed by ART.
By making ART a Mainline module in Android 12, Google made this core OS component updatable through Google Play System Updates instead of through OTA updates that your OEM or carrier have to push out.
This lets Google:
* Roll out runtime and compiler optimizations that lead to better performance
* Push out upstream OpenJDK fixes more quickly
* Issue runtime and compiler security fixes faster
* Deliver new OpenJDK core language features
One recent change in Android 14 is the refactoring of the interface between the Package Manager and ART. This refactoring "moves the OS boundary from the ART dex2oat command line to a well-defined interface that enables future optimizations, such as fine-grained control over the compilation mode."
Starting in Android 14, OEMs can customize on-device AOT compilation for apps through system properties and APIs. Basically opening up A/B testing of compilation.
A couple of other points worth highlighting:
* On select Android 13+ devices that support the Android Virtualization Framework (like the Pixel 6 and Pixel 7 series), secure compilation of bootclasspath and system server JARs happens while the device is idle rather than on first reboot after an ART update, saving up to 20 seconds of boot time.
* Upcoming ART releases are tested every day by compiling over 18 million APKs (!) and running app compatibility tests as well as startup, performance, and memory benchmarks on a variety of Android devices.
* Runtime and compiler optimizations in the ART 13 update "delivered real-world app start-up improvements of up to 30% on some devices."
* ART 14 will be released "in the coming months" to compatible devices. ART 14 includes OpenJDK 17 support and new compiler and runtime optimizations.
ART provides the runtime and core APIs that "all apps and most OS services rely on." As Google explains, both Java and Kotlin code are compiled down to bytecode that's executed by ART.
By making ART a Mainline module in Android 12, Google made this core OS component updatable through Google Play System Updates instead of through OTA updates that your OEM or carrier have to push out.
This lets Google:
* Roll out runtime and compiler optimizations that lead to better performance
* Push out upstream OpenJDK fixes more quickly
* Issue runtime and compiler security fixes faster
* Deliver new OpenJDK core language features
One recent change in Android 14 is the refactoring of the interface between the Package Manager and ART. This refactoring "moves the OS boundary from the ART dex2oat command line to a well-defined interface that enables future optimizations, such as fine-grained control over the compilation mode."
Starting in Android 14, OEMs can customize on-device AOT compilation for apps through system properties and APIs. Basically opening up A/B testing of compilation.
A couple of other points worth highlighting:
* On select Android 13+ devices that support the Android Virtualization Framework (like the Pixel 6 and Pixel 7 series), secure compilation of bootclasspath and system server JARs happens while the device is idle rather than on first reboot after an ART update, saving up to 20 seconds of boot time.
* Upcoming ART releases are tested every day by compiling over 18 million APKs (!) and running app compatibility tests as well as startup, performance, and memory benchmarks on a variety of Android devices.
* Runtime and compiler optimizations in the ART 13 update "delivered real-world app start-up improvements of up to 30% on some devices."
* ART 14 will be released "in the coming months" to compatible devices. ART 14 includes OpenJDK 17 support and new compiler and runtime optimizations.
🔥35👍9🤔4
Contrary to popular belief, you can use eSIM phone plans without needing a phone that supports eSIM.
Why would you want that? Many prepaid eSIM plans are very cheap and can be bought ahead of travel, but most phones don't have an eSIM chip built-in.
So how does this work?
The tl;dr is that eSIM is actually a specification that is implemented by a UICC, or universal integrated circuit card. Phones with eSIM support have an eUICC (embedded UICC) chip, but there's nothing preventing a vendor from making a traditional nano SIM-sized card with an eUICC that follows the eSIM spec. These are called "removable eUICCs" and are actually used in IoT devices, but their use in mobile devices is still somewhat new.
A few companies have popped up that sell you removable eUICCs, like eSIM.me and esim.5ber.com, but it's also possible to DIY your own.
There are tutorials online on how to take an off-the-shelf eUICC chip, remove the original chip in a nano SIM, and then weld the eUICC chip onto the card. Some Chinese retailers also sell the finished product for pretty cheap, but you can't just buy it, insert it into your device, and then download an eSIM profile.
That's because you need a way to actually provision the eSIM plan onto the removable eUICC. Most Android phones with eSIM built-in ship with an app that does this, like SIM Manager on Pixels (shown above), but these apps won't work with removable eUICCs you insert. Companies like eSIM.me and 5ber offer apps that work with their own products, but if you go the DIY route, you'll need to use something like OpenEUICC.
OpenEUICC is an open source app for Android that allows for provisioning eSIM profiles onto removable eUICCs. It requires certain system privileges to function, so you need a phone with root access to provision an eSIM plan. Once a plan is provisioned onto the card, though, you can use it on any device that has a SIM card slot.
If you want to learn more about removable eUICCs and how eSIMs work in general, check out this article I wrote last year.
Why would you want that? Many prepaid eSIM plans are very cheap and can be bought ahead of travel, but most phones don't have an eSIM chip built-in.
So how does this work?
The tl;dr is that eSIM is actually a specification that is implemented by a UICC, or universal integrated circuit card. Phones with eSIM support have an eUICC (embedded UICC) chip, but there's nothing preventing a vendor from making a traditional nano SIM-sized card with an eUICC that follows the eSIM spec. These are called "removable eUICCs" and are actually used in IoT devices, but their use in mobile devices is still somewhat new.
A few companies have popped up that sell you removable eUICCs, like eSIM.me and esim.5ber.com, but it's also possible to DIY your own.
There are tutorials online on how to take an off-the-shelf eUICC chip, remove the original chip in a nano SIM, and then weld the eUICC chip onto the card. Some Chinese retailers also sell the finished product for pretty cheap, but you can't just buy it, insert it into your device, and then download an eSIM profile.
That's because you need a way to actually provision the eSIM plan onto the removable eUICC. Most Android phones with eSIM built-in ship with an app that does this, like SIM Manager on Pixels (shown above), but these apps won't work with removable eUICCs you insert. Companies like eSIM.me and 5ber offer apps that work with their own products, but if you go the DIY route, you'll need to use something like OpenEUICC.
OpenEUICC is an open source app for Android that allows for provisioning eSIM profiles onto removable eUICCs. It requires certain system privileges to function, so you need a phone with root access to provision an eSIM plan. Once a plan is provisioned onto the card, though, you can use it on any device that has a SIM card slot.
If you want to learn more about removable eUICCs and how eSIMs work in general, check out this article I wrote last year.
👍44🤯13🔥1👌1
Android 14 has a hidden feature that lets the OS automatically add the URL of a web page you screenshot.
So eg. if you take a screenshot of a page then hit share, the URL will also be included with the image.
Video + full details available for Patrons/X subscribers.
So eg. if you take a screenshot of a page then hit share, the URL will also be included with the image.
Video + full details available for Patrons/X subscribers.
👍55🥰7❤🔥6🖕6🤔4🎉4👎2
Through Project Mainline, Google says that phones running Android 12+ have received updates improving app startup performance by up to 30% (on some devices).
Better performance isn't all that Mainline updates have brought, though. Here's what you need to know about Project Mainline changes in Android 14 - and a sneak peek at what to expect for Mainline in Android 15 👀
Read more on AndroidPolice.
Better performance isn't all that Mainline updates have brought, though. Here's what you need to know about Project Mainline changes in Android 14 - and a sneak peek at what to expect for Mainline in Android 15 👀
Read more on AndroidPolice.
Android Police
What you need to know about Project Mainline in Android 14 and beyond
Project Mainline delivers key OS updates through Google Play — here's how it's changing
👍32
Google Play Services is starting to roll out a big redesign of its settings page. I'm referring to the page you access by going to Settings > Google.
Now, instead of showing the full list of settings by default, you'll get quick access to a couple of key settings in the "recommended" tab. The "all services" tab houses the remaining settings.
I got this new UI after updating Google Play Services to version 23.33.14, but I only see it on one of my devices. Let me know if you see this new UI on your device - it's long overdue, IMO!
Now, instead of showing the full list of settings by default, you'll get quick access to a couple of key settings in the "recommended" tab. The "all services" tab houses the remaining settings.
I got this new UI after updating Google Play Services to version 23.33.14, but I only see it on one of my devices. Let me know if you see this new UI on your device - it's long overdue, IMO!
👍40🌚3