Android 14 Beta 1 is here! This is the first Android 14 release that’s available for users enrolled in the Android Beta program! Follow me on Twitter to see my full breakdown of what’s new, but first, read my summary here of what Google announced.

Android 14 is introducing an important security feature that authenticator apps can use to block malware from stealing your 2FA codes, like how the “Cerberus” banking trojan and “Nexus” malware were caught snooping on Google Authenticator. Here’s what you should know 👇

The Accessibility API lets apps read the contents of the screen and perform inputs on behalf of the user. It’s intended for screen readers and alternative input systems, but it’s open to any app. Malware authors love abusing this API.

Well-known malware like Cerberus and Nexus have been reported to use Accessibility to read 2FA codes from Google Authenticator. Currently, if an app’s malicious Accessibility Service is enabled, there’s nothing stopping them from doing that.

In Android 14, though, apps can set an attribute to prevent non-accessibility tools from interacting with important Views. Google Authenticator eg. can ensure that only accessibility tools can read 2FA codes.

For more information on this new #Android14 security feature, including a video that shows how it can block malware from reading your 2FA codes, check out my latest article for Esper.

If you’re a content creator looking to cover Android 14 Beta 1, I made a document that summarizes ALL the changes I’ve found in Android 14 so far. I’ve made it as simple as possible without sacrificing technical accuracy. Send me a DM if you want to take a look!

I plan to turn this doc into an article after cleaning it up a bit. I’ve documented almost every change I’ve spotted so far and will continue to keep it updated. All I have left to summarize are some developer-oriented changes, which is why I’m opening this up to creators now.

Follow this thread if you want to see EVERYTHING that’s new in Android 14 Beta 1!

Android 14 Beta 1 adds a “transparent navigation bar” toggle to Developer Options that “make[s] [the] navigation bar background color transparent by default.” More details on how this feature works in this article on XDA-Developers.

Google Wallet may be bringing back location-based suggestions for loyalty cards in Android 14 👀

It used to have this feature, but it's been missing since the app relaunched last year!

Full details in my latest article for XDA-Developers!

Some have reported that the max number of custom actions an app can add to the share sheet using Android 14's ChooserAction API is 7.

That's how many I added using Tasker, but the actual limit is much higher than that, as pointed out by @thegreatporg and shown off in this video.

The actual limit seems to just be 1MB for the Bundle size.

Neat: A developer built an unofficial Nearby Share client for macOS!

It currently supports receiving files from Android over WiFi LAN only, but the fact that it even works is impressive in and of itself. I wouldn't be surprised to hear that Google's building its own macOS client, but this could be useful if you need to send files right now!

Original Reddit post by the developer | NearDrop on GitHub

Screenshot credit: @bhusankumar2k2

According to the latest Android version distribution statistics shared by Google (via 9to5Google), the % of (GMS Android) devices running Android 13 has more than doubled since January 2023 - from 5% to 12.1%.

Other changes:

- Android 12: 18.9% -> 16.5%
- Android 11: 24.4% -> 23.5%
- Android 10: 19.5% -> 18.5%
- Android 9: 13.2% -> 12.3%
- Android 8: 9.5% -> 6.7%
- Android 7: 3.7% -> 3.3%
- Android 6: 2.8% -> 2.5%
- Android 5: 2.1% -> 1.9%
- Android 4.4: 0.7% -> 0.6%

If you want to better visualize these stats in pie chart format, 9to5Google's article has 'em.

The updated statistics are not yet available through Android Studio, presumably they're only shown on the backend for now.

Android 14 is bringing a couple of enhancements to Dynamic System Updates (DSU), the feature that lets you boot a generic Android build without overwriting the original installation.

These include:

1) Ability to install a new data partition without supplying a new system image, in case you want to simulate a factory reset.

2) Ability to reboot immediately into the dynamic system when installation is completed.

3) Ability to set "sticky mode" - ie. persist the dynamic system across reboots - during installation rather than post-install.

4) Ability to hide the notification about the status of the dynamic system (in use or ready) so OEMs can customize the UI.

5) Ability to use the default strings provided by keyguard manager when showing the dialog that prompts the user for device credentials.

H/T @onenormalusername

These DSU changes probably came in response to feedback from OEMs. There are surprisingly a couple of OEMs who actually use DSU to let users test Android betas, like Sharp did with their Android 13 beta.

Alongside the release of Android 14 Beta 1 for Pixel, Google also released Generic System Images (GSIs) for Android 14 B1! Same build (UPB1.230309.014) and SPL (April 2023) but they're installable on (theoretically) any Project Treble-compatible device - excluding devices with an Android 9 vendor.

In general, it isn't recommended for you to install a GSI through DSU - there's a chance you could brick your phone if the bootloader isn't unlocked because of Android Verified Boot (AVB).

Theoretically you should be able to boot these Android 14 GSIs on Pixels running Android 13 QPR2 WITHOUT unlocking the bootloader since Google installed the GSI keys in the ramdisk, which would let you boot a developer GSI with AVB enabled. This applies to Tensor-based Pixels, coral (Pixel 4 XL), sunfish (Pixel 4a), redbull (Pixel 4a with 5G and Pixel 5).

I don't know if they reverted this change in the QPR3 Beta, so YMMV. Also, the developer_gsi_keys makefile only lists the Q, R, and S GSI AVB pubkeys, not T or U. It's possible they're using the same key now to sign the T and U GSIs, but I haven't tested.

If you want to test booting the Android 14 GSI on your Pixel running Android 13 QPR2+ (again, I HAVEN'T TESTED IF THIS WILL BRICK YOUR PHONE OR WORK), you have to do so manually (or use DSU Sideloader), because Google hasn't updated gsi-src.json to point to the U GSIs yet.

EDIT:

It seems Google literally just updated the gsi-src json to point to the Android 14 GSIs, so they should now appear as an option for you to install in the DSU Loader menu!

(I swear the json didn't have this when I drafted this post, lol!)

According to one user, they were able to boot up the Android 14 Beta 1 GSI on their Pixel 7 which had a locked bootloader and was running the April 2023 Android 13 QPR2 stable release.

Google is preparing to add "Super Wideband" (SWB) Speech support to Android's Bluetooth stack which (I assume) enables even higher-quality voice transmission over the Bluetooth Hands-Free Profile (HFP)!

This will use the LC3 codec over HFP. In comparison, the codec behind the current "Wideband Speech" (WBS) is mSBC. I don't know exactly how improved voice audio coded in LC3 will sound compared to mSBC - will have to wait for audio samples to find out.

One of the code changes also mentions the Bluetooth stack adding support for HFP 1.9. The currently adopted HFP spec is 1.8.

H/T luca020400 on Twitter

EDIT:

The Bluetooth SIG apparently already has a page covering Super Wide Band Speech and HFP 1.9.

HFP 1.9 hasn't been adopted yet, so the document that describes it is a WIP. Here's Appendix E: Technical Specification of LC3-SWB.

Google Messages appears to be rolling out end-to-end encryption support for group RCS chats for users on the latest stable release (version messages.android_20230329_00_RC01.phone_dynamic).

H/T SeeAreEff on Twitter

Android is preparing to add support for "Valet Key", which I assume refers to a way to securely & temporarily share a digital car key for valet parking. A new system property and SELinux policy for "valet key" have been added, but that's it - no details on the implementation.

With the December 2022 Pixel Feature Drop, Google rolled out the ability to share a digital car key with your (trusted) friends and family. AFAIK, there's currently no way to temporarily grant someone access to your DCK unless you manually grant then remember to revoke access.

Now here's where things get weird. How exactly will you share your DCK temporarily with the valet? Would a temporarily valid credential be transferred to a receiving device via Nearby Share or something? Would you have to text/send them a link? Hand them (!) your phone?

Handing the valet your phone doesn't sound ideal...but that might be how this works? Hear me out.

The SELinux policy that Google set up gives the Settings app r/w access to /metadata/valetkey. This lets it write /metadata/valetkey/enabled to indicate a valet key is enabled.

The status of the valet key is only readable to apps if /metadata/valetkey/enabled exists, ro.valetkey.enabled is true, and a GSI (?) is running.

Why would this be conditioned on whether a GSI is running? Maybe your phone will boot into a GSI temporarily so when you hand your phone over to the valet, your data will be inaccessible to them?
It's a wild theory for sure, but there's so little information to go on!

Oh, and I looked at the CCC v3 specification. There isn't really a section on how valet keys work, but there is a mention of a "valet parking key" as one of the standard profiles in section 11.6 Key Configuration.

This feature has now been announced.

The prompt will appear on devices running Android 7.0+ when an app in the foreground crashes and there's a more stable version of the app available on Google Play.