TIL that some OEMs just ... didn't implement Android 13's per-app language feature, which lets users set a different language for each app!
OnePlus didn't add it in OxygenOS 13 (and I presume neither did OPPO in ColorOS 13) nor did Xiaomi in MIUI 14.
It's always hard to tell when a certain feature Google adds to Android is going to be available across all devices. I do my best to find out by looking at whether the feature is Pixel exclusive first (Google introduces some features they never explicitly say are Pixel only) then whether there's going to be a CDD/GMS requirement regarding it.
As far as I can tell, per-app language settings isn't mentioned anywhere in the CDD/GMS reqs, but I'm pretty sure most OEMs implemented it. I know Samsung, ASUS, and Nothing have, for example.
As for why OnePlus/OPPO and Xiaomi didn't implement this feature, I can only guess. Perhaps they encountered some issue they couldn't resolve or maybe they felt it wasn't worth supporting (it's in AOSP though so it's there by default).
In the case of OnePlus and I presume OPPO as well, at least they plan on adding this feature in their Android 14 update! Frequent OnePlus tipster @OneNormalUsername discovered that the closed beta of OxygenOS 14 has the per-app language feature. (Credits for the screenshot of per-app language settings in OxygenOS 14 go to Aamir Siddiqui.)
In the case of Xiaomi, I asked frequent tipster @kacskrz about it, but they said they aren't sure if the feature is coming in Android 14-based builds of MIUI. However, the per-app language settings are still there and can be launched manually through an activity launcher.
As an alternative, you can use the "Language Selector" app which uses the Shizuku library to gain shell user privileges to access the locale manager CLI.
OnePlus didn't add it in OxygenOS 13 (and I presume neither did OPPO in ColorOS 13) nor did Xiaomi in MIUI 14.
It's always hard to tell when a certain feature Google adds to Android is going to be available across all devices. I do my best to find out by looking at whether the feature is Pixel exclusive first (Google introduces some features they never explicitly say are Pixel only) then whether there's going to be a CDD/GMS requirement regarding it.
As far as I can tell, per-app language settings isn't mentioned anywhere in the CDD/GMS reqs, but I'm pretty sure most OEMs implemented it. I know Samsung, ASUS, and Nothing have, for example.
As for why OnePlus/OPPO and Xiaomi didn't implement this feature, I can only guess. Perhaps they encountered some issue they couldn't resolve or maybe they felt it wasn't worth supporting (it's in AOSP though so it's there by default).
In the case of OnePlus and I presume OPPO as well, at least they plan on adding this feature in their Android 14 update! Frequent OnePlus tipster @OneNormalUsername discovered that the closed beta of OxygenOS 14 has the per-app language feature. (Credits for the screenshot of per-app language settings in OxygenOS 14 go to Aamir Siddiqui.)
In the case of Xiaomi, I asked frequent tipster @kacskrz about it, but they said they aren't sure if the feature is coming in Android 14-based builds of MIUI. However, the per-app language settings are still there and can be launched manually through an activity launcher.
As an alternative, you can use the "Language Selector" app which uses the Shizuku library to gain shell user privileges to access the locale manager CLI.
😡27👍12💩7❤2🤔2
Android 14 is introducing a new safety feature called "headphone loud sound alerts". This is REALLY important. Way too many people suffer from hearing loss because they listened to music at excessively loud volumes for too long.
I know I talked about headphone loud sound alerts before, but the last time I did, I didn't have:
a) Google's source code for the feature.
b) The $452 standards doc this feature is based on.
Thanks to Google's SDK 34 release and a source for providing the doc, I now have both!
This time around, I also did the totally sane thing and tested the feature out by playing a 10-hour long YouTube video of air horn sounds.
Before you comment that your phone already has this feature, please read the article! All the details about it as well as how it compares to the existing safe media volume feature you're probably familiar with can be found in the Android Police article, so give it a read!
I know I talked about headphone loud sound alerts before, but the last time I did, I didn't have:
a) Google's source code for the feature.
b) The $452 standards doc this feature is based on.
Thanks to Google's SDK 34 release and a source for providing the doc, I now have both!
This time around, I also did the totally sane thing and tested the feature out by playing a 10-hour long YouTube video of air horn sounds.
Before you comment that your phone already has this feature, please read the article! All the details about it as well as how it compares to the existing safe media volume feature you're probably familiar with can be found in the Android Police article, so give it a read!
👍46❤11👎6🎉4
Google has now confirmed the work profile changes I first reported on last month. ie. Android 14 now actually pauses - instead of turns off - your work profile. This means your work profile remains running, though apps are suspended.
This new behavior is now mentioned on the "what's new in enterprise in Android 14" page. App developers should read this page to get ready for this change, as there are some things you need to be aware of when it comes to notifications and how to listen for changes to work profile status.
For the full rundown on this change and what it means for users, refer to this article I wrote last month.
(Thanks to @AssembleDebug for notifying me that Google updated their page!)
This new behavior is now mentioned on the "what's new in enterprise in Android 14" page. App developers should read this page to get ready for this change, as there are some things you need to be aware of when it comes to notifications and how to listen for changes to work profile status.
For the full rundown on this change and what it means for users, refer to this article I wrote last month.
(Thanks to @AssembleDebug for notifying me that Google updated their page!)
👍16🔥9❤2😢1
This is something a lot of people aren't aware of - just how many tests Google requires OEMs to run before they can push an Android software build through!
Off the top of my head, there are 9:
* CTS (Compatibility Test Suite)
* VTS (Vendor Test Suite)
* CTS-on-GSI (Compatibility Test Suite on Generic System Image)
* GTS (Google Test Suite)
* CTS-V (Compatibility Test Suite Verifier)
* ITS (Image Test Suite, technically part of CTS-V)
* BTS (Build Test Suite)
* STS (Security Test Suite)
* MTS (Mainline Test Suite)
Collectively, this series of tests is referred to as xTS for short.
Not all of these have to be re-run with every subsequent OTA, to be fair. But these are just the test suites, which don't cover ALL the requirements OEMs have to follow, which are laid out in the CDD (Compatibility Definition Document), GMS Requirements (Google Mobile Services Requirements), VSR (Vendor Software Requirements), and other documents.
By the way, each test by itself can take anywhere from hours to days, so the entire testing process can end up taking several days. There are some tricks to speed these up, like sharding (parallelizing test by running them on multiple devices), though.
There are also programs like GMS Express that can help cut down on testing time. SoC vendors like MediaTek and UNISOC offer BSPs that pass xTS already, reducing the time it takes to get a build out.
(Fun fact: OEMs don't submit their test results directly to Google. Instead, Google contracts out the certification process to 3PLs [third-party labs].)
Off the top of my head, there are 9:
* CTS (Compatibility Test Suite)
* VTS (Vendor Test Suite)
* CTS-on-GSI (Compatibility Test Suite on Generic System Image)
* GTS (Google Test Suite)
* CTS-V (Compatibility Test Suite Verifier)
* ITS (Image Test Suite, technically part of CTS-V)
* BTS (Build Test Suite)
* STS (Security Test Suite)
* MTS (Mainline Test Suite)
Collectively, this series of tests is referred to as xTS for short.
Not all of these have to be re-run with every subsequent OTA, to be fair. But these are just the test suites, which don't cover ALL the requirements OEMs have to follow, which are laid out in the CDD (Compatibility Definition Document), GMS Requirements (Google Mobile Services Requirements), VSR (Vendor Software Requirements), and other documents.
By the way, each test by itself can take anywhere from hours to days, so the entire testing process can end up taking several days. There are some tricks to speed these up, like sharding (parallelizing test by running them on multiple devices), though.
There are also programs like GMS Express that can help cut down on testing time. SoC vendors like MediaTek and UNISOC offer BSPs that pass xTS already, reducing the time it takes to get a build out.
(Fun fact: OEMs don't submit their test results directly to Google. Instead, Google contracts out the certification process to 3PLs [third-party labs].)
👍40😱6🤔2
You may eventually be able to use your Android TV as a Bluetooth speaker
I've spotted evidence that suggests you'll be able to turn your Android TV/Google TV device into a Bluetooth speaker for your phone or other Bluetooth-enabled devices.
Currently, most Android TV/Google TV devices only support acting as a Bluetooth audio source device, but that could change in a future release.
Full details available exclusively to Patrons/X subscribers.
I've spotted evidence that suggests you'll be able to turn your Android TV/Google TV device into a Bluetooth speaker for your phone or other Bluetooth-enabled devices.
Currently, most Android TV/Google TV devices only support acting as a Bluetooth audio source device, but that could change in a future release.
Full details available exclusively to Patrons/X subscribers.
👍37🔥5
"Crossdrop is a partial implementation of Google's Nearby Share in Flutter for macOS, iOS and Linux"👀
Developer PlutoHDDev is working on porting Google's Nearby Share to more platforms, starting with Linux first!
Crossdrop is still a work-in-progress, so it's not feature-complete nor stable enough for production use. It's based on NearDrop, a previous port of Nearby Share to macOS, made by developer grishka.
CrossDrop on GitHub | Documentation on Google's Nearby Share protocol | My previous post on NearDrop
Developer PlutoHDDev is working on porting Google's Nearby Share to more platforms, starting with Linux first!
Crossdrop is still a work-in-progress, so it's not feature-complete nor stable enough for production use. It's based on NearDrop, a previous port of Nearby Share to macOS, made by developer grishka.
CrossDrop on GitHub | Documentation on Google's Nearby Share protocol | My previous post on NearDrop
❤48👍11🔥11
Heads up to any AOSP platform developers: Google is apparently deprecating AIDEGen.
In its place, Google is recommending "ASfP", which apparently stands for "Android Studio for Platform".
This is casually mentioned in the README file for the new RemoteAuth Mainline module (if you're wondering what that this, see this Patron-only post).
AIDEGen, for those unaware, enables you to configure your preferred IDE (like IntelliJ or Android Studio) for platform app development.
There are some problems with using AIDEGen, though, according to one experienced platform developer I've spoken to. These include:
* When you start a new target, it needs to "recompile" makefiles. This could take a few minutes.
* You need to run Android Studio locally, which can be annoying if you're trying to build on a remote server.
* To run a change, the "run" button in Android Studio might not work so instead you need to go back to the console.
Google has been working on making it easier to use Android Studio for platform app development, but I'm not entirely sure if ASfP will solve all these issues since I don't have access to the documentation that Google linked.
In its place, Google is recommending "ASfP", which apparently stands for "Android Studio for Platform".
This is casually mentioned in the README file for the new RemoteAuth Mainline module (if you're wondering what that this, see this Patron-only post).
AIDEGen, for those unaware, enables you to configure your preferred IDE (like IntelliJ or Android Studio) for platform app development.
There are some problems with using AIDEGen, though, according to one experienced platform developer I've spoken to. These include:
* When you start a new target, it needs to "recompile" makefiles. This could take a few minutes.
* You need to run Android Studio locally, which can be annoying if you're trying to build on a remote server.
* To run a change, the "run" button in Android Studio might not work so instead you need to go back to the console.
Google has been working on making it easier to use Android Studio for platform app development, but I'm not entirely sure if ASfP will solve all these issues since I don't have access to the documentation that Google linked.
👍18🥱1
The Google Messages app is preparing to let you send an emergency SOS over a satellite connection!
Emergency SOS on iPhone has proven to be an incredibly helpful feature, even contributing to saving some lives in the recent Maui wildfire.
(Although Neïl Rahmouni most recently tipped me on this, I have to shout-out @AssembleDebug as well who posted about this last week in the Telegram group!)
Although the emergency SOS activity in the Messages app is currently a placeholder, it should be of no surprise that Google is adding this feature, given that they've already said they're working to enable satellite support in Android 14. Plus, Google Messages is the default messaging app on many Android phones from different brands, so it needs to support this feature so that a separate messaging app won't have to be built for phones that support satellite connectivity.
By the way, if you're curious about the status of satellite support in Android, check out this post (and the subsequent ones) I posted recently that dives into the Android 14 source code that Google recently posted.
Emergency SOS on iPhone has proven to be an incredibly helpful feature, even contributing to saving some lives in the recent Maui wildfire.
(Although Neïl Rahmouni most recently tipped me on this, I have to shout-out @AssembleDebug as well who posted about this last week in the Telegram group!)
Although the emergency SOS activity in the Messages app is currently a placeholder, it should be of no surprise that Google is adding this feature, given that they've already said they're working to enable satellite support in Android 14. Plus, Google Messages is the default messaging app on many Android phones from different brands, so it needs to support this feature so that a separate messaging app won't have to be built for phones that support satellite connectivity.
By the way, if you're curious about the status of satellite support in Android, check out this post (and the subsequent ones) I posted recently that dives into the Android 14 source code that Google recently posted.
👍44🔥4
Google Keep is FINALLY starting to roll out text formatting support!
I just updated the Google Keep Android app to version 5.23.322.05 and got the feature.
It seems the feature is slowly rolling out to some users. Let me know if text formatting is enabled for you!
(Tipster AssembleDebug showed off the feature a couple of days ago, but they manually enabled it on a rooted device by flipping some flags. In contrast, I just updated my app and got the feature.)
I just updated the Google Keep Android app to version 5.23.322.05 and got the feature.
It seems the feature is slowly rolling out to some users. Let me know if text formatting is enabled for you!
(Tipster AssembleDebug showed off the feature a couple of days ago, but they manually enabled it on a rooted device by flipping some flags. In contrast, I just updated my app and got the feature.)
❤53👍15🔥6🥰6❤🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Google Keep is also getting version history support!
Here's a first look at the feature, courtesy of @AssembleDebug.
Version history was first spotted by Artem Russakovski a few hours ago, but it's labeled as "coming soon" for them (as well as for myself).
Here's a first look at the feature, courtesy of @AssembleDebug.
Version history was first spotted by Artem Russakovski a few hours ago, but it's labeled as "coming soon" for them (as well as for myself).
🔥38👍21🥰1
Watch Unlock may not be exclusive to the Pixel Watch! It may also be available on Samsung's Galaxy Watch 6 and earlier Galaxy Watch models!
Watch Unlock is an upcoming feature that will make it easier to unlock your phone when regular biometric authentication fails, like when your fingers are wet or face isn't recognized. When your watch is unlocked, on your wrist, and within reach of your phone, your watch will automatically unlock your phone when you swipe up on the lock screen.
Earlier today, 9to5Google spotted the listing for the Pixel Watch 2 on the Google Play Console's device catalog. The listing suggests the smartwatch will have Qualcomm's Snapdragon W5 chip, as previously rumored, as well as 2GB of RAM and run Android 13-based Wear OS 4.
But the listing also reveals that the Pixel Watch 2 will support "Active Unlock", the internal name for the Android 13 API that powers the upcoming Watch Unlock feature. It specifically declares the
Using this as a filter in the Play Console, I discovered that the Galaxy Watch 6 series also declares the Active Unlock feature!
However, the earlier Galaxy Watch 4 and Galaxy Watch 5 series do not at this time. These watches will also likely support Active Unlock, however, once they upgrade to One UI Watch 5 based on Android 13, which should be rolling out soon. (In the Play Console, the Watch 4/5 series are both still listed as running Android 11, hence the updated software build has not yet been submitted to the console's database.)
Watch Unlock is an upcoming feature that will make it easier to unlock your phone when regular biometric authentication fails, like when your fingers are wet or face isn't recognized. When your watch is unlocked, on your wrist, and within reach of your phone, your watch will automatically unlock your phone when you swipe up on the lock screen.
Earlier today, 9to5Google spotted the listing for the Pixel Watch 2 on the Google Play Console's device catalog. The listing suggests the smartwatch will have Qualcomm's Snapdragon W5 chip, as previously rumored, as well as 2GB of RAM and run Android 13-based Wear OS 4.
But the listing also reveals that the Pixel Watch 2 will support "Active Unlock", the internal name for the Android 13 API that powers the upcoming Watch Unlock feature. It specifically declares the
com.google.android.clockwork.active_unlock feature.Using this as a filter in the Play Console, I discovered that the Galaxy Watch 6 series also declares the Active Unlock feature!
However, the earlier Galaxy Watch 4 and Galaxy Watch 5 series do not at this time. These watches will also likely support Active Unlock, however, once they upgrade to One UI Watch 5 based on Android 13, which should be rolling out soon. (In the Play Console, the Watch 4/5 series are both still listed as running Android 11, hence the updated software build has not yet been submitted to the console's database.)
❤23👍8🆒2🔥1
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