According to the "What's new in Google System Updates" page, version 33.4 of the Google Play Store app will bring the app archiving feature. Version 33.2.12 is the latest, though, so the feature hasn't rolled out yet.
Even if you're on v33.4 of the Google Play Store app, though, you may not see the feature immediately. It's controlled server-side and likely won't roll out widely until Google formally announces the rollout.
Here's what it'll look like, by the way.
Even if you're on v33.4 of the Google Play Store app, though, you may not see the feature immediately. It's controlled server-side and likely won't roll out widely until Google formally announces the rollout.
Here's what it'll look like, by the way.
👍11👏1
OnePlus now joins Samsung in promising 4 platform upgrades and 5 years of security updates, though this is only for "selected devices" in 2023 and security updates will be "bi-monthly".
Extended software support is mostly a matter of cost and resources. With initiatives like Project Treble, GKI, Project Mainline, and GRF, Android has become more and more modular, and thus easier (and cheaper) to upgrade.
There is a caveat, though. GRF, or Google Requirements Freeze, makes it *more* difficult for OEMs to support N+4 letter upgrades, as they'll have to upgrade the vendor software from N to N+4 on their own. It's not impossible, just more work. We'll have to see how long it takes OnePlus to roll out the 4th letter upgrade for these "selected devices".
Google promises 3 letter upgrades and 5 years of security updates - both generally day 1 releases - which is less than what Samsung and now OnePlus promise. Hopefully other OEMs (and Google) follow suit in offering extended software support soon.
Extended software support is mostly a matter of cost and resources. With initiatives like Project Treble, GKI, Project Mainline, and GRF, Android has become more and more modular, and thus easier (and cheaper) to upgrade.
There is a caveat, though. GRF, or Google Requirements Freeze, makes it *more* difficult for OEMs to support N+4 letter upgrades, as they'll have to upgrade the vendor software from N to N+4 on their own. It's not impossible, just more work. We'll have to see how long it takes OnePlus to roll out the 4th letter upgrade for these "selected devices".
Google promises 3 letter upgrades and 5 years of security updates - both generally day 1 releases - which is less than what Samsung and now OnePlus promise. Hopefully other OEMs (and Google) follow suit in offering extended software support soon.
XDA
OnePlus commits to four major Android updates, five years of security updates for "selected devices"
OnePlus has committed to four platform updates for "selected devices", and five years of security patches.
🔥6🤔1🤮1
Google is working on making OTA updates faster. A new set of patches has been submitted to AOSP that speed up OTAs on devices that use the virtual A/B with compression update mechanism. Combined, these improvements bring a full OTA install time from ~23 minutes to ~13 minutes!
The first improvement is to batch write COW operations in a cluster. The second improvement is to use two threads to compress the snapshot.
Android's OTA update mechanisms can get a bit confusing, but this article I wrote a few weeks back explains all of them (including the newer virtual A/B with compression that's used on Pixels and is being improved here!)
H/T Luca Stefani for the heads up
The first improvement is to batch write COW operations in a cluster. The second improvement is to use two threads to compress the snapshot.
Android's OTA update mechanisms can get a bit confusing, but this article I wrote a few weeks back explains all of them (including the newer virtual A/B with compression that's used on Pixels and is being improved here!)
H/T Luca Stefani for the heads up
🔥13👍7❤1
Android's Bluetooth stack supports A2DP source and sink roles, but not both simultaneously. Most Android devices (apart from Automotive) are A2DP sources to stream audio to Bluetooth headphones. If you want to also be able to stream audio via BT to an Android device, what can you do?
The other day, I spotted this patch in AOSP that modifies Android's Bluetooth stack to support simultaneous A2DP source/sink functionality. It was submitted by a MediaTek engineer and hasn't been merged, but what's interesting is the Googler's comment suggesting this functionality be limited only to Android TV devices. Most Android TV devices are set up as A2DP sources.
There may have been some offline/internal discussion about this I'm missing, but this could be something we'll see in Android TV 14! Imagine being able to stream any audio from your phone/tablet to your TV, without needing Google Cast (as not every app supports it.)
The lack of simultaneous A2DP source/sink functionality is hindering my AAOS-on-TabS5e project. I want to be able to stream audio from my phone (when I use Android Auto) as well as from the tablet (to use my car's speakers).
(For context, A2DP is the "Advanced Audio Distribution Profile", the standard Bluetooth Classic profile used for streaming audio to remote devices.
A "source" device is where the audio originates, while a "sink" device is where the audio is played.)
The other day, I spotted this patch in AOSP that modifies Android's Bluetooth stack to support simultaneous A2DP source/sink functionality. It was submitted by a MediaTek engineer and hasn't been merged, but what's interesting is the Googler's comment suggesting this functionality be limited only to Android TV devices. Most Android TV devices are set up as A2DP sources.
There may have been some offline/internal discussion about this I'm missing, but this could be something we'll see in Android TV 14! Imagine being able to stream any audio from your phone/tablet to your TV, without needing Google Cast (as not every app supports it.)
The lack of simultaneous A2DP source/sink functionality is hindering my AAOS-on-TabS5e project. I want to be able to stream audio from my phone (when I use Android Auto) as well as from the tablet (to use my car's speakers).
(For context, A2DP is the "Advanced Audio Distribution Profile", the standard Bluetooth Classic profile used for streaming audio to remote devices.
A "source" device is where the audio originates, while a "sink" device is where the audio is played.)
👍7🔥1
"What's new in Google System Updates" has been updated to list December 2022 changes. Notably:
* Beta support for adding a mobile driver's license issued by select US states to Google Wallet
* Inform the user if a tablet they're trying to cast to needs user interaction
At I/O 2022, Google said it was working with state governments in the U.S. and around the world to bring mobile driver's license support to Google Wallet. This feature is finally launching, though we still don't know which states will support it first.
Android has been ready for mobile driver's licenses for some time now (Identity Credential API was added in Android 11), so this has been a long time coming. The challenge has primarily been regulatory/political.
It's worth noting that the Android 14 VSR will require that launch devices support the Identity Credential HAL. This will enable mobile driver's licenses stored on Android devices to be even more securely stored.
—-
As for the tablet/cast change, given that the Pixel Tablet will likely double as a smart display, it's not surprising you'll be able to cast to it. However, there may be scenarios where you have to do something (unlock? change profiles?) before you can cast to it.
* Beta support for adding a mobile driver's license issued by select US states to Google Wallet
* Inform the user if a tablet they're trying to cast to needs user interaction
At I/O 2022, Google said it was working with state governments in the U.S. and around the world to bring mobile driver's license support to Google Wallet. This feature is finally launching, though we still don't know which states will support it first.
Android has been ready for mobile driver's licenses for some time now (Identity Credential API was added in Android 11), so this has been a long time coming. The challenge has primarily been regulatory/political.
It's worth noting that the Android 14 VSR will require that launch devices support the Identity Credential HAL. This will enable mobile driver's licenses stored on Android devices to be even more securely stored.
—-
As for the tablet/cast change, given that the Pixel Tablet will likely double as a smart display, it's not surprising you'll be able to cast to it. However, there may be scenarios where you have to do something (unlock? change profiles?) before you can cast to it.
👍12
For December 2022's Android Feature Drop, Google's bringing:
- New styles in Google Photos' collage editor
- New holiday-themed emoji in Gboard's Emoji Kitchen
- A dedicated Reading Mode app
- YouTube home screen search widget
- Select a device to cast to from the Google TV app
- Share your digital car key within Google Wallet with other Pixel and iPhone users (and soon users on other select phones running Android 12+)
- New Wear OS tiles (favorite contacts, sunrise/sunset) & updated Keep app
Full details (and images/GIFs) in Google's blog post.
By the way, this Feature Drop is for all GMS Android users, not just Pixel users. (Google doesn't officially call it the "Android Feature Drop" anymore, but I like it so I'm still calling it that.) Next week, Pixel users will likely be treated to their Pixel Feature Drop for December 2022.
- New styles in Google Photos' collage editor
- New holiday-themed emoji in Gboard's Emoji Kitchen
- A dedicated Reading Mode app
- YouTube home screen search widget
- Select a device to cast to from the Google TV app
- Share your digital car key within Google Wallet with other Pixel and iPhone users (and soon users on other select phones running Android 12+)
- New Wear OS tiles (favorite contacts, sunrise/sunset) & updated Keep app
Full details (and images/GIFs) in Google's blog post.
By the way, this Feature Drop is for all GMS Android users, not just Pixel users. (Google doesn't officially call it the "Android Feature Drop" anymore, but I like it so I'm still calling it that.) Next week, Pixel users will likely be treated to their Pixel Feature Drop for December 2022.
🔥13👍5😢3🤮2👌2
Google has announced that Android 13 is the first Android release where the majority of new code is written in a memory safe language. About 21% of all new native code added to Android 13 is written in Rust.
Support for Rust was introduced in Android 12. There are now approximately 1.5 million total lines of Rust code for new AOSP components such as Keystore2, the Ultra-wideband stack, DNS-over-HTTP/3, the Android Virtualization Framework, and more.
The drop in memory safety vulnerabilities (223 in 2019 to 85 in 2022) and the severity of vulnerabilities overall have been credited to Google's shift away from memory unsafe languages. 2022 is the first year where memory safety vulnerabilities aren't a majority of Android vulns.
Google's using Rust for new, low-level Android components & doesn't plan to convert existing code written in C/C++ (media, Bluetooth, NFC, etc.). However, they're improving the safety of Android's C/C++ code with things like the Scudo hardened allocator, HWASAN, GWP-ASAN, & KFENCE, as well as improved fuzzing.
And Google will continue to grow the use of Rust in the Android platform.
"We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers."
I recommend reading the full blog post by Jeff Vander Stoep. It goes into a lot more detail!
Support for Rust was introduced in Android 12. There are now approximately 1.5 million total lines of Rust code for new AOSP components such as Keystore2, the Ultra-wideband stack, DNS-over-HTTP/3, the Android Virtualization Framework, and more.
The drop in memory safety vulnerabilities (223 in 2019 to 85 in 2022) and the severity of vulnerabilities overall have been credited to Google's shift away from memory unsafe languages. 2022 is the first year where memory safety vulnerabilities aren't a majority of Android vulns.
Google's using Rust for new, low-level Android components & doesn't plan to convert existing code written in C/C++ (media, Bluetooth, NFC, etc.). However, they're improving the safety of Android's C/C++ code with things like the Scudo hardened allocator, HWASAN, GWP-ASAN, & KFENCE, as well as improved fuzzing.
And Google will continue to grow the use of Rust in the Android platform.
"We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers."
I recommend reading the full blog post by Jeff Vander Stoep. It goes into a lot more detail!
Google Online Security Blog
Memory Safe Languages in Android 13
Posted by Jeff Vander Stoep For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerab...
🔥17👏6👍1
Folks, this is bad news. Very, very bad. Hackers and/or malicious insiders have leaked the platform certificates of several vendors. These are used to sign system apps on Android builds, including the "android" app itself. These certs are being used to sign malicious Android apps!
Why is that a problem? Well, it lets malicious apps opt into Android's shared user ID mechanism and run with the same highly privileged user ID as "android" - android.uid.system. Basically, they have the same authority/level of access as the Android OS process!
(Here's a short summary of shared UID, from my Android 13 deep dive.)
The post on the Android Partner Vulnerability Initiative issue tracker shared SHA256 hashes of the platform signing certificates and correctly signed malware using those certificates. Thanks to sites like
VirusTotal and APKMirror, it's trivial to see who is affected...
So, for example, this malware sample. Scroll down to the certificate subject/issuer, and whose name do you see? The biggest Android OEM on the planet? Yeah, yikes.
Go to APKMirror and just search for the SHA256 hash of the corresponding platform signing certificate... Yeah, this certificate is still being used to sign apps.
That's just one example. There are others at risk, too.
In any case, Google recommends that affected parties should rotate the platform certificate, conduct an investigation into how this leak happened, and minimize the number of apps signed with the platform certificate, so that future leaks won't be as devastating.
Why is that a problem? Well, it lets malicious apps opt into Android's shared user ID mechanism and run with the same highly privileged user ID as "android" - android.uid.system. Basically, they have the same authority/level of access as the Android OS process!
(Here's a short summary of shared UID, from my Android 13 deep dive.)
The post on the Android Partner Vulnerability Initiative issue tracker shared SHA256 hashes of the platform signing certificates and correctly signed malware using those certificates. Thanks to sites like
VirusTotal and APKMirror, it's trivial to see who is affected...
So, for example, this malware sample. Scroll down to the certificate subject/issuer, and whose name do you see? The biggest Android OEM on the planet? Yeah, yikes.
Go to APKMirror and just search for the SHA256 hash of the corresponding platform signing certificate... Yeah, this certificate is still being used to sign apps.
That's just one example. There are others at risk, too.
In any case, Google recommends that affected parties should rotate the platform certificate, conduct an investigation into how this leak happened, and minimize the number of apps signed with the platform certificate, so that future leaks won't be as devastating.
😱27🔥5👀3👍2😭2
Mishaal's Android News Feed
Folks, this is bad news. Very, very bad. Hackers and/or malicious insiders have leaked the platform certificates of several vendors. These are used to sign system apps on Android builds, including the "android" app itself. These certs are being used to sign…
Okay, so what are the immediate implications/takeaways for users?
- You can't trust that an app has been signed by the legitimate vendor/OEM if their platform certificate was leaked. Do not sideload those apps from third-party sites/outside of Google Play or trusted OEM store.
- This may affect updates to apps that are delivered through app stores if the OEM rotates the signing key, depending on whether or not that app has a V3 signature or not. V3 signature scheme supports key rotation, older schemes do not.
OEMs are not required to sign system apps with V3 signatures. The minimum signature scheme version for apps targeting API level 30+ on the system partition is V2. You can check the signature scheme using the apksigner tool.
Affected OEMs can still rotate the cert used to sign their system apps that have V2 signatures and then push an OTA update to deliver the updated apps. Then they can push app updates with that new cert, but devices that haven't received OTAs won't receive those app updates.
The leaked platform signing certificates can't be used to install compromised OTA updates, thankfully.
- You can't trust that an app has been signed by the legitimate vendor/OEM if their platform certificate was leaked. Do not sideload those apps from third-party sites/outside of Google Play or trusted OEM store.
- This may affect updates to apps that are delivered through app stores if the OEM rotates the signing key, depending on whether or not that app has a V3 signature or not. V3 signature scheme supports key rotation, older schemes do not.
OEMs are not required to sign system apps with V3 signatures. The minimum signature scheme version for apps targeting API level 30+ on the system partition is V2. You can check the signature scheme using the apksigner tool.
Affected OEMs can still rotate the cert used to sign their system apps that have V2 signatures and then push an OTA update to deliver the updated apps. Then they can push app updates with that new cert, but devices that haven't received OTAs won't receive those app updates.
The leaked platform signing certificates can't be used to install compromised OTA updates, thankfully.
😢10👍5🔥1😐1
End-to-end encryption for group chats in Google Messages is starting to roll out!
End-to-end encryption for 1:1 chats became available for everyone mid-2021. At their I/O 2022 keynote earlier this year, Google said that end-to-end encryption for group chats would be enabled later this year.
(H/T Twitter user SeeAreEff)
EDIT:
Some additional info: User SeeAreEff is on the latest beta release of Google Messages (version 20221129_00_RC01.phone.openbeta_dynamic) and the latest stable release of Google Play Services (version 22.46.17). They said that their buddy, Andy, is using an Android phone.
End-to-end encryption for 1:1 chats became available for everyone mid-2021. At their I/O 2022 keynote earlier this year, Google said that end-to-end encryption for group chats would be enabled later this year.
(H/T Twitter user SeeAreEff)
EDIT:
Some additional info: User SeeAreEff is on the latest beta release of Google Messages (version 20221129_00_RC01.phone.openbeta_dynamic) and the latest stable release of Google Play Services (version 22.46.17). They said that their buddy, Andy, is using an Android phone.
👍21👎1
Mishaal's Android News Feed
Okay, so what are the immediate implications/takeaways for users? - You can't trust that an app has been signed by the legitimate vendor/OEM if their platform certificate was leaked. Do not sideload those apps from third-party sites/outside of Google Play…
Statement from Google given to @9to5Google.
I think the best protection Google can offer is through Play Protect. If you install a new app that was signed by a leaked platform cert, Play Protect should be able to check if that app matches.
I think the best protection Google can offer is through Play Protect. If you install a new app that was signed by a leaked platform cert, Play Protect should be able to check if that app matches.
👍34
Mishaal's Android News Feed
End-to-end encryption for group chats in Google Messages is starting to roll out! End-to-end encryption for 1:1 chats became available for everyone mid-2021. At their I/O 2022 keynote earlier this year, Google said that end-to-end encryption for group chats…
Google has officially announced the rollout of end-to-end encryption for group chats in Messages. This "will be available to some users in the open beta program over the coming weeks." Also, Google says that you'll soon be able to react to RCS messages with any emoji.
Google
Happy birthday and farewell, SMS! It's time for RCS
SMS has been around for 30 years, and Messages by Google has the perfect gift to celebrate: RCS.
👍17🥰4
Google has announced the release of Android 13 for TV today, but the new release is only available right now for the ADT-3 developer platform and the Android TV emulator.
If you want a full, detailed breakdown of what's new for TVs in Android 13, I've got you covered with this blog post.
If you want a full, detailed breakdown of what's new for TVs in Android 13, I've got you covered with this blog post.
Android Developers Blog
Android 13 for TV is now available
Posted by Wolfram Klein, Product Manager, Android TV OS
👍11
This media is not supported in your browser
VIEW IN TELEGRAM
Google is testing a "Send" shortcut in the Nearby Share bottom sheet that lets you quickly select files (using the Files by Google app) to share with others. This shortcut will appear when you tap the Quick Setting tile for Nearby Share.
Yes, you can already share files through Nearby Share. However, you have to open another app, select file(s) to share, hit share, & then pick Nearby Share. This cuts out some steps and makes the QS tile actually useful (before it just let you change visibility or open settings).
H/T t.me/google_nws
Yes, you can already share files through Nearby Share. However, you have to open another app, select file(s) to share, hit share, & then pick Nearby Share. This cuts out some steps and makes the QS tile actually useful (before it just let you change visibility or open settings).
H/T t.me/google_nws
👍15🔥6👏2
Google has been working on making it easier to do platform app development using Android Studio, and this latest code change in AOSP seems to bring them one step closer.
(AOSP code change in question: Export framework turbine stubs as android_stubs_private)
You're probably familiar with Android Studio, but you can't develop platform apps (like SystemUI) using it, at least not out of the box.
One of the issues is that only public APIs are available through the SDK that Android Studio downloads. Platform apps frequently call hidden/private/system APIs.
To solve this, one solution is to replace the SDK's android.jar file with one that contains all Android framework APIs, enabling platform app development through Android Studio.
(You can build your own android.jar to unlock all platform APIs by compiling AOSP and then extracting the JAR before it gets dexed. H/T @phhusson for that info. Another method is detailed here.)
Google's solution seems similar, except it's not replacing android.jar in the SDK path but instead adding an android_private_stubs JAR containing stubs for non-private APIs, so Android Studio won't throw a fit when you try to call them. More importantly, they'll probably maintain this so you won't need to manually create your own JAR for each Android release!
(There are other methods to enable AOSP platform app development on Android Studio, eg. a tool called AIDEGen is offered to configure your preferred IDE for platform app development.)
Back in March, the Android Studio team was hiring someone to help make Studio usable for Android OS development. This effort seems related to that role.
(AOSP code change in question: Export framework turbine stubs as android_stubs_private)
You're probably familiar with Android Studio, but you can't develop platform apps (like SystemUI) using it, at least not out of the box.
One of the issues is that only public APIs are available through the SDK that Android Studio downloads. Platform apps frequently call hidden/private/system APIs.
To solve this, one solution is to replace the SDK's android.jar file with one that contains all Android framework APIs, enabling platform app development through Android Studio.
(You can build your own android.jar to unlock all platform APIs by compiling AOSP and then extracting the JAR before it gets dexed. H/T @phhusson for that info. Another method is detailed here.)
Google's solution seems similar, except it's not replacing android.jar in the SDK path but instead adding an android_private_stubs JAR containing stubs for non-private APIs, so Android Studio won't throw a fit when you try to call them. More importantly, they'll probably maintain this so you won't need to manually create your own JAR for each Android release!
(There are other methods to enable AOSP platform app development on Android Studio, eg. a tool called AIDEGen is offered to configure your preferred IDE for platform app development.)
Back in March, the Android Studio team was hiring someone to help make Studio usable for Android OS development. This effort seems related to that role.
👍12❤3🔥2
A trifecta of releases today: the December 2022 Android Security Bulletin, the first Android 13 Quarterly Platform Release (QPR), and the December 2022 Pixel Feature Drop!
—-
The December 2022 Android Security Bulletin is live!
- 4 critical severity vulnerabilities in AOSP components (CVE-2022-20472, CVE-2022-20473, CVE-2022-20411, and CVE-2022-20498) 3 of which are RCE vulnerabilities and 1 of which is related to Bluetooth.
- 4 vulnerabilities in Project Mainline components
—-
The announcement for the Pixel update went live on the Pixel support forum today. The build number is TQ1A.221205.01X and is available for the Pixel 4a and later.
Apart from new features, the list of bug fixes is MASSIVE, as is usually the case with the first QPR following a new letter release.
—-
The December 2022 Android Security Bulletin is live!
- 4 critical severity vulnerabilities in AOSP components (CVE-2022-20472, CVE-2022-20473, CVE-2022-20411, and CVE-2022-20498) 3 of which are RCE vulnerabilities and 1 of which is related to Bluetooth.
- 4 vulnerabilities in Project Mainline components
—-
The announcement for the Pixel update went live on the Pixel support forum today. The build number is TQ1A.221205.01X and is available for the Pixel 4a and later.
Apart from new features, the list of bug fixes is MASSIVE, as is usually the case with the first QPR following a new letter release.
👍12