Mobvoi has finally rolled out the Wear OS 3 update they promised for the TicWatch Pro 3! The OS version is Wear OS 3.5 (RMRB.231020.007) based on Android 11 with the October 2023 patches.
The update factory resets the watch, but it was really easy to set it up again thanks to Fast Pair. Sadly, the smartwatch doesn't have Google Assistant support anymore. I've already moved onto the Pixel Watch 2, but at least the new update means you can use some previously unavailable apps like Google Home.
The update factory resets the watch, but it was really easy to set it up again thanks to Fast Pair. Sadly, the smartwatch doesn't have Google Assistant support anymore. I've already moved onto the Pixel Watch 2, but at least the new update means you can use some previously unavailable apps like Google Home.
👍38🤬16❤5🥱2
Here's how Google will simplify sideloading in Android.
As part of a proposed class action lawsuit settlement, Google said it will revise the default sideloading flow in Android. Here's exactly what they're changing:
1) The pop-up with the text "For your security, your phone currently isn't allowed to install unknown apps from this source. You can change this in Settings" and the "Install unknown apps" screen that lets you enable sideloading from the specified source will be combined into a single screen. That means you won't have to visit Settings to enable sideloading from a specified source anymore.
2) The text in this combined screen will read as follows: "Your phone currently isn't configured to install apps from this source. Granting this source permission to install apps could place your phone and data at risk."
Google will have to maintain this revised default sideloading flow for a period of five years after it's implemented, and they cannot "introduce additional material complexity or burden into the Revised Default Sideloading Flow solely because an app was sideloaded, as opposed to being downloaded from Google Play."
Source: 6.10 Sideloading from the Settlement Agreement and Release document
As part of a proposed class action lawsuit settlement, Google said it will revise the default sideloading flow in Android. Here's exactly what they're changing:
1) The pop-up with the text "For your security, your phone currently isn't allowed to install unknown apps from this source. You can change this in Settings" and the "Install unknown apps" screen that lets you enable sideloading from the specified source will be combined into a single screen. That means you won't have to visit Settings to enable sideloading from a specified source anymore.
2) The text in this combined screen will read as follows: "Your phone currently isn't configured to install apps from this source. Granting this source permission to install apps could place your phone and data at risk."
Google will have to maintain this revised default sideloading flow for a period of five years after it's implemented, and they cannot "introduce additional material complexity or burden into the Revised Default Sideloading Flow solely because an app was sideloaded, as opposed to being downloaded from Google Play."
Source: 6.10 Sideloading from the Settlement Agreement and Release document
👍97😁9👨💻7
Big news! Google has announced the details of its settlement with the more than 30 U.S. states that filed a class action lawsuit over Google Play.
Google says it will:
1) Be "further simplifying the sideloading process and updating the language that informs users about these potential risks of downloading apps directly from the web for the first time." More details here.
2) Allow app and game developers to "implement an alternative billing option alongside Google Play's billing system for their U.S. users who can then choose which option to use when making in-app purchases."
3) Allow developers to "show different pricing options within the app when a user makes a digital purchase."
4) Pay $630 million into a settlement fund that will be distributed according to a Court-approved plan. $70 million will go to a fund that will be used by the states.
There's a bunch of other changes that Google agreed to as part of the settlement. The Verge's Sean Hollister has an excellent summary you can read here.
Google says it will:
1) Be "further simplifying the sideloading process and updating the language that informs users about these potential risks of downloading apps directly from the web for the first time." More details here.
2) Allow app and game developers to "implement an alternative billing option alongside Google Play's billing system for their U.S. users who can then choose which option to use when making in-app purchases."
3) Allow developers to "show different pricing options within the app when a user makes a digital purchase."
4) Pay $630 million into a settlement fund that will be distributed according to a Court-approved plan. $70 million will go to a fund that will be used by the states.
There's a bunch of other changes that Google agreed to as part of the settlement. The Verge's Sean Hollister has an excellent summary you can read here.
The Verge
Google to pay $700 million and make tiny app store changes to settle with 50 states
This won’t be nearly enough for Epic Games.
👏56👍21👾10😐5😱2🍾2❤1🎉1
Mishaal's Android News Feed
Following the Bluetooth, WiFi, and UWB stacks, Google will next turn Android's NFC stack into a modular system component, ie. a Project Mainline module! It's too early for this to happen in Android 14, but the NFC stack could become a Mainline module as early…
Earlier this year, I said that Google planned to make the NFC stack an updatable Project Mainline module in a future Android release.
Well, it's been a few months, and that indeed seems to be coming true. Work to turn the NFC stack into a Mainline module is still ongoing, but there's now a placeholder APEX module in AOSP as well as code changes to move all NFC-related classes to a new framework-nfc.jar file that will be updated via the APEX file.
Next year's Android 15 release could be the earliest we'll see the new NFC Mainline module.
Well, it's been a few months, and that indeed seems to be coming true. Work to turn the NFC stack into a Mainline module is still ongoing, but there's now a placeholder APEX module in AOSP as well as code changes to move all NFC-related classes to a new framework-nfc.jar file that will be updated via the APEX file.
Next year's Android 15 release could be the earliest we'll see the new NFC Mainline module.
👍53🤷♂8🔥7❤2
When Google's Find My Device Network actually launches, one feature I'm hoping will be ready is powered-off finder, which will let devices continue sending Bluetooth beacons after Android is shut down. This will make it possible to locate devices when they're powered off or out of battery*.
UI support for this feature was added in Android 14 QPR1, while Google Play Services has also been preparing for this feature over the last few months. And earlier this month, code for the Bluetooth Finder HAL was merged to AOSP.
This HAL has the "API to enable the powered-off finder feature, which allows the Bluetooth controller to send beacons after the device is powered off." Google Play Services will use this API to send precomputed "Finder Network" keys to the device's Bluetooth chip so that it can continue broadcasting to other nearby devices on the FMDN.
I don't know when this feature will be ready, let alone when the FMDN will launch. As I said earlier this month, Google is waiting on Apple to implement unwanted tracker detection into iOS before rolling out the FMDN on Android. And Apple won't implement unwanted tracker detection into iOS until the specification they're working on with Google is finalized. Google said this spec should be finalized by the end of this year.
*Yes, I realize you still need some battery to power to the Bluetooth chip. Obviously I'm referring to when there's not enough battery to boot up Android, or some power is simply reserved for this purpose.
UI support for this feature was added in Android 14 QPR1, while Google Play Services has also been preparing for this feature over the last few months. And earlier this month, code for the Bluetooth Finder HAL was merged to AOSP.
This HAL has the "API to enable the powered-off finder feature, which allows the Bluetooth controller to send beacons after the device is powered off." Google Play Services will use this API to send precomputed "Finder Network" keys to the device's Bluetooth chip so that it can continue broadcasting to other nearby devices on the FMDN.
I don't know when this feature will be ready, let alone when the FMDN will launch. As I said earlier this month, Google is waiting on Apple to implement unwanted tracker detection into iOS before rolling out the FMDN on Android. And Apple won't implement unwanted tracker detection into iOS until the specification they're working on with Google is finalized. Google said this spec should be finalized by the end of this year.
*Yes, I realize you still need some battery to power to the Bluetooth chip. Obviously I'm referring to when there's not enough battery to boot up Android, or some power is simply reserved for this purpose.
👍59👀6
Developers Sergio Prado and Chris Simmonds did a talk recently about what's new in AOSP 14 (the open source release of Android 14), and to accompany the talk, Sergio shared some interesting statistics about the source code size, build time, and more.
It's wild to see how much AOSP has grown since Android 8 Oreo's release in 2017. AOSP 14's source code size is 165GB compared to AOSP 8's 87GB. The build output size has gone up to 150GB with AOSP 14 versus 87GB with AOSP 8.
Obviously build times can be optimized with better hardware, but we're well past the point where building on your own hardware makes sense. (I've built AOSP 13 locally with an 11th gen i7 + 32GB RAM + 1TB NVMe Windows PC via WSL a few times, and it's painful.) For those of you who build AOSP, what kind of hardware (local or cloud) do you currently use? How long does it take to compile a fresh build?
Some other interesting tidbits:
1) Memory usage in AOSP 13 was 1.8GB versus 3.6GB (!) in AOSP 14. That's a huge increase. The minimum RAM requirement for devices to run Android 13 Go Edition was 2GB, but there's no word yet on if that will be bumped for Android 14 Go Edition.
2) The default ro filesystem is now EROFS in AOSP 14. I reported earlier that Google has been wanting to shift the default ro filesystem to this, but they hit a snag with last year's Pixel 7 release when they discovered an app launch time regression. The default rw filesystem is now F2FS, but that's less interesting to me since Google has already been using that in its own Pixel hardware.
It's wild to see how much AOSP has grown since Android 8 Oreo's release in 2017. AOSP 14's source code size is 165GB compared to AOSP 8's 87GB. The build output size has gone up to 150GB with AOSP 14 versus 87GB with AOSP 8.
Obviously build times can be optimized with better hardware, but we're well past the point where building on your own hardware makes sense. (I've built AOSP 13 locally with an 11th gen i7 + 32GB RAM + 1TB NVMe Windows PC via WSL a few times, and it's painful.) For those of you who build AOSP, what kind of hardware (local or cloud) do you currently use? How long does it take to compile a fresh build?
Some other interesting tidbits:
1) Memory usage in AOSP 13 was 1.8GB versus 3.6GB (!) in AOSP 14. That's a huge increase. The minimum RAM requirement for devices to run Android 13 Go Edition was 2GB, but there's no word yet on if that will be bumped for Android 14 Go Edition.
2) The default ro filesystem is now EROFS in AOSP 14. I reported earlier that Google has been wanting to shift the default ro filesystem to this, but they hit a snag with last year's Pixel 7 release when they discovered an app launch time regression. The default rw filesystem is now F2FS, but that's less interesting to me since Google has already been using that in its own Pixel hardware.
👍66🤔14🤡4🙈3👀2
Mishaal's Android News Feed
This article made me curious about the status of the unwanted tracker detection specification, and it appears that work is indeed ongoing. The latest message in the mailing list comes from an Apple employee dated Nov. 30, and ends with "I think we're close…
Version 01 of the "Detecting Unwanted Location Trackers" specification has just been uploaded to the IETF! This is the unwanted tracker specification that Google and Apple are jointly developing.
Google already rolled out unwanted tracker alerts in Android earlier this year, but it's based on a custom implementation. Apple is allegedly waiting for this specification to be finalized before rolling out unwanted tracker alerts in iOS. Google says that they're waiting on Apple to do that before they roll out the Find My Device Network on Android.
So the closer this specification comes to being finalized, the closer we are to the launch of Android's Find My Device Network!
(H/T BjoernDroege on Twitter)
Google already rolled out unwanted tracker alerts in Android earlier this year, but it's based on a custom implementation. Apple is allegedly waiting for this specification to be finalized before rolling out unwanted tracker alerts in iOS. Google says that they're waiting on Apple to do that before they roll out the Find My Device Network on Android.
So the closer this specification comes to being finalized, the closer we are to the launch of Android's Find My Device Network!
(H/T BjoernDroege on Twitter)
👍74❤1
Finally! Android is preparing to show you an estimate of your battery's remaining charge capacity, so you'll know when to replace it.
You can see a screenshot of the Pixel's new "battery health" page and read more details about this feature in my latest article for Android Authority.
Bonus details in the article: Android may soon know whether you've replaced your battery or not by checking its serial number.
(Thanks to @nailsad_eleos for the tip!)
You can see a screenshot of the Pixel's new "battery health" page and read more details about this feature in my latest article for Android Authority.
Bonus details in the article: Android may soon know whether you've replaced your battery or not by checking its serial number.
(Thanks to @nailsad_eleos for the tip!)
Android Authority
Android may soon tell you when it's time to replace your phone's battery
Android is preparing to give you an estimate of the remaining capacity of your phone's battery, making it easier to know when to replace it.
🔥64👍26👏5❤4❤🔥2
Interesting: It looks like Google might be rebranding Nearby Share to Quick Share. Quick Share is notably the name of Samsung's file sharing service on Galaxy devices. Are these two services going to be merged?
More details in my article for Android Authority, via Kamila Wojciechowska.
More details in my article for Android Authority, via Kamila Wojciechowska.
Android Authority
Google and Samsung might be merging Nearby Share and Quick Share
Google's Nearby Share service could be rebranded as Quick Share, which is the same name as Samsung's file sharing service.
👍76😨26🔥12🤔7🥰4🤡4👎3👌2🤯1
Google wants to deprecate Android Protected Confirmation due to low adoption from OEMs.
Android Protected Confirmation is a security feature introduced in Android 9 that "leverages a hardware protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system." Through an API, apps can invoke APC to allow the user to confirm the transaction by double pressing the power button when the Trusted UI is shown.
When APC was first introduced, Google showcased how several partners planned to leverage this feature, such for person-to-person money transfers, user authentication, and medical device control. In an April 2023 blog post, Google even said that APC was "gaining ecosystem attention as an industry-leading method for confirming critical user actions via hardware" and that work on a pilot project to establish Protected Confirmation as a "common application programmable interface standard" was ongoing.
However, last month, two patches were uploaded by Googlers to AOSP that deprecate the HAL for APC. The reason they gave is that "Pixel is the only OEM that supported Trusted UI and we want to remove the APC/TUI. It has low adoption." The patches haven't been submitted yet until "product discussions" are concluded, but the fact that only Pixel has adopted APC after all these years doesn't bode well for the future of this feature.
Android Protected Confirmation is a security feature introduced in Android 9 that "leverages a hardware protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system." Through an API, apps can invoke APC to allow the user to confirm the transaction by double pressing the power button when the Trusted UI is shown.
When APC was first introduced, Google showcased how several partners planned to leverage this feature, such for person-to-person money transfers, user authentication, and medical device control. In an April 2023 blog post, Google even said that APC was "gaining ecosystem attention as an industry-leading method for confirming critical user actions via hardware" and that work on a pilot project to establish Protected Confirmation as a "common application programmable interface standard" was ongoing.
However, last month, two patches were uploaded by Googlers to AOSP that deprecate the HAL for APC. The reason they gave is that "Pixel is the only OEM that supported Trusted UI and we want to remove the APC/TUI. It has low adoption." The patches haven't been submitted yet until "product discussions" are concluded, but the fact that only Pixel has adopted APC after all these years doesn't bode well for the future of this feature.
😢57👍19🤷♂6🤔4🤡4👎1
Google has published the Android Security Bulletin (ASB) for January 2024, detailing the vulnerabilities addressed in the 2024-01-0X security patch level (SPL). Patches are available for Android versions 11-14. This is the first ASB of 2024 🎉
This month, there aren't any vulnerabilities in AOSP components with a severity rating of "critical". There's one vulnerability in the Media Codecs Mainline module that will be addressed in the January 2024 Google Play System Update, which will also bring an update to the Android Runtime (ART) module that addresses the GC-related crash some apps with native code are having.
Speaking of the January 2024 GPSU, it should also bring the new userfaultfd-based GC algorithm to Android 13 devices. This new GC algorithm went live for Android 14 devices in November 2023 and is expected to roll out to Android 12 devices in February 2024.
This month, there aren't any vulnerabilities in AOSP components with a severity rating of "critical". There's one vulnerability in the Media Codecs Mainline module that will be addressed in the January 2024 Google Play System Update, which will also bring an update to the Android Runtime (ART) module that addresses the GC-related crash some apps with native code are having.
Speaking of the January 2024 GPSU, it should also bring the new userfaultfd-based GC algorithm to Android 13 devices. This new GC algorithm went live for Android 14 devices in November 2023 and is expected to roll out to Android 12 devices in February 2024.
❤39👍16😁1
Android 14 made streaming apps to your Windows PC slightly more annoying
If you use Link to Windows on an Android smartphone that supports streaming apps, you may have noticed that, after the Android 14 update, you have to tap "start now" every single time you want to mirror your screen or an app. In previous releases, you only had to do this generally once per boot. This means that you now have to reach over to your phone every time you want to launch a new app.
You don't have to do this if you're using Chrome OS's app streaming feature on Android 14, so what gives? Turns out that Android 14 changed the way that the MediaProjection API behaves. MediaProjection is the API that apps use to record the screen. To avoid having to ask the user for permission to capture the screen every time, many screen recorder apps and apps like Link to Windows would reuse the same intent returned by the API. Doing this now in Android 14 throws a SecurityException.
This is an intentional change by Google to force apps to ask the user to give consent before each capture session, but it definitely makes app streaming through Link to Windows more annoying until Microsoft finds a workaround. App streaming to Chromebooks isn't affected because Cross-Device Services uses the new privileged Companion App Streaming APIs in Android 13 rather than MediaProjection.
If you use Link to Windows on an Android smartphone that supports streaming apps, you may have noticed that, after the Android 14 update, you have to tap "start now" every single time you want to mirror your screen or an app. In previous releases, you only had to do this generally once per boot. This means that you now have to reach over to your phone every time you want to launch a new app.
You don't have to do this if you're using Chrome OS's app streaming feature on Android 14, so what gives? Turns out that Android 14 changed the way that the MediaProjection API behaves. MediaProjection is the API that apps use to record the screen. To avoid having to ask the user for permission to capture the screen every time, many screen recorder apps and apps like Link to Windows would reuse the same intent returned by the API. Doing this now in Android 14 throws a SecurityException.
This is an intentional change by Google to force apps to ask the user to give consent before each capture session, but it definitely makes app streaming through Link to Windows more annoying until Microsoft finds a workaround. App streaming to Chromebooks isn't affected because Cross-Device Services uses the new privileged Companion App Streaming APIs in Android 13 rather than MediaProjection.
🥱35🤡20🥴8👍7🤔6👎1👌1
How to mirror your Samsung device's screen to Google Cast-enabled devices via Smart View
Smart View is Samsung's screen mirroring service available on Galaxy devices running One UI. By default, it only supports mirroring your device's screen to TVs/displays that support Miracast. Many Android TV/Nest devices only support Google Cast, not Miracast, so in order to mirror your screen to them, you'd need to use the Google Home app.
However, Smart View is preparing to add support for Google Cast, so you can use Samsung's built-in service to mirror your screen to both Miracast and Google Cast-enabled devices. Here's how to enable the feature right now!
First, check what version of Smart View is installed on your device. Go to Settings > Connected devices > Smart View and tap the three-dot menu then "Settings" followed by "About Smart View". On version 8.2.20.19, you can use the method discovered in July 2023 to access the hidden "SmartView developer option" page to enable the "Google Cast" toggle.
If you're on a newer version of the Smart View app (like 8.2.22.24), the old method won't work. However, it's still possible to access the hidden developer option page! Here are two ways to do it:
1) Download the SystemUI Tuner app, go through its setup process, tap the "System" dropdown on the leftdown then select "Lock Screen". Tap on "Lock Screen Shortcuts", then pick either the Left or Right shortcut. Look for "Smart View" in the app list and then pick the option that says
(Credits go to Redditor Proshis_Saha_Swopna for the SystemUI Tuner method, H/T to LordServerReset on Twitter for bringing it to my attention.)
2) Run this single ADB command:
Then launch the lock screen shortcut like in #1.
(1/2)
Smart View is Samsung's screen mirroring service available on Galaxy devices running One UI. By default, it only supports mirroring your device's screen to TVs/displays that support Miracast. Many Android TV/Nest devices only support Google Cast, not Miracast, so in order to mirror your screen to them, you'd need to use the Google Home app.
However, Smart View is preparing to add support for Google Cast, so you can use Samsung's built-in service to mirror your screen to both Miracast and Google Cast-enabled devices. Here's how to enable the feature right now!
First, check what version of Smart View is installed on your device. Go to Settings > Connected devices > Smart View and tap the three-dot menu then "Settings" followed by "About Smart View". On version 8.2.20.19, you can use the method discovered in July 2023 to access the hidden "SmartView developer option" page to enable the "Google Cast" toggle.
If you're on a newer version of the Smart View app (like 8.2.22.24), the old method won't work. However, it's still possible to access the hidden developer option page! Here are two ways to do it:
1) Download the SystemUI Tuner app, go through its setup process, tap the "System" dropdown on the leftdown then select "Lock Screen". Tap on "Lock Screen Shortcuts", then pick either the Left or Right shortcut. Look for "Smart View" in the app list and then pick the option that says
DeveloperOptionActivity. Now go to the lock screen, and on the lock screen, open the shortcut you just set. It should launch the SmartView developer option page!(Credits go to Redditor Proshis_Saha_Swopna for the SystemUI Tuner method, H/T to LordServerReset on Twitter for bringing it to my attention.)
2) Run this single ADB command:
adb shell "settings put system lock_application_shortcut '1;com.samsung.android.smartmirroring/.settings.DeveloperOptionActivity;1;null;'"Then launch the lock screen shortcut like in #1.
(1/2)
👍22❤5👏3
Mishaal's Android News Feed
How to mirror your Samsung device's screen to Google Cast-enabled devices via Smart View Smart View is Samsung's screen mirroring service available on Galaxy devices running One UI. By default, it only supports mirroring your device's screen to TVs/displays…
It's actually quite funny how this works. The SmartView app's developer option activity is unexported, which means you can't launch it using a normal activity launcher or through ADB shell unless you have root access. However, the system user is able to launch unexported activities, so by manually changing the lock screen shortcut to the developer option activity, we can make the SystemUI (which runs as the system user) launch it for us. Good thing that the lock screen shortcuts on One UI devices can still be changed by modifying a Settings table value.
(2/2)
(2/2)
👍34
How to use your Samsung phone as a secondary monitor for your Windows PC
One UI has a feature called Second Screen that lets you mirror/extend your Windows PC's screen onto your Samsung device. However, this feature is officially only available on the Galaxy Tab S7, Tab S8, and Tab S9 series.
Fortunately, the feature is still there on Samsung phones and foldables like the Galaxy Z Fold 5, but you need to access its hidden settings page in order to use it. Here's how.
1) Download the SystemUI Tuner app from Google Play, go through its setup process, tap the "System" dropdown on the leftdown then select "Lock Screen". Tap on "Lock Screen Shortcuts", then pick either the Left or Right shortcut. Look for "Smart View" in the app list and then pick the option that says
OR
2) Run the following ADB command:
After you do #1 or #2, go to the lock screen and open the shortcut you just set. It should launch the Second Screen settings page! The reason this works is because, although the Second Screen activity is unexported, the lock screen is part of SystemUI which runs as the system user which can launch unexported activities.
Now while you're on this page, hit Windows + K on your PC to bring up the Cast menu. You should see your device appear here. Pick it, and wait for it to connect. Once it connects, open up the Cast menu again and check the "allow mouse, keyboard, touch, and pen input from this device" if you want to be able to send inputs from your phone. That's it!
Kudos to FragmentedChicken for the tip! Let me know if you find other useful activities you can launch with this lock screen shortcut method.
One UI has a feature called Second Screen that lets you mirror/extend your Windows PC's screen onto your Samsung device. However, this feature is officially only available on the Galaxy Tab S7, Tab S8, and Tab S9 series.
Fortunately, the feature is still there on Samsung phones and foldables like the Galaxy Z Fold 5, but you need to access its hidden settings page in order to use it. Here's how.
1) Download the SystemUI Tuner app from Google Play, go through its setup process, tap the "System" dropdown on the leftdown then select "Lock Screen". Tap on "Lock Screen Shortcuts", then pick either the Left or Right shortcut. Look for "Smart View" in the app list and then pick the option that says
SecondScreenActivity. OR
2) Run the following ADB command:
adb shell "settings put system lock_application_shortcut '1;com.samsung.android.smartmirroring/com.samsung.android.smartmirroring.player.SecondScreenActivity;1;null;'"After you do #1 or #2, go to the lock screen and open the shortcut you just set. It should launch the Second Screen settings page! The reason this works is because, although the Second Screen activity is unexported, the lock screen is part of SystemUI which runs as the system user which can launch unexported activities.
Now while you're on this page, hit Windows + K on your PC to bring up the Cast menu. You should see your device appear here. Pick it, and wait for it to connect. Once it connects, open up the Cast menu again and check the "allow mouse, keyboard, touch, and pen input from this device" if you want to be able to send inputs from your phone. That's it!
Kudos to FragmentedChicken for the tip! Let me know if you find other useful activities you can launch with this lock screen shortcut method.
❤34👍14👀8🔥3