Oh neat, Find My Device v3 also finally adds a themed icon!

Left: v2.5
Right: v3

(Yes, the icon itself has been updated as well.)

If you're thinking, "wait, Find My Device already had a themed icon!" No, it didn't, at least not unless you were on a Pixel.

Google has announced new apps and features for Android Auto and Android Automotive.

These include:

* WebEx by Cisco and Zoom are now rolling out with audio-only capability, so you can join scheduled meetings and conference calls from your car display. (The arrival of these apps was announced last week, but the actual rollout begins today.)

* Amazon Prime Video is now available on select cars with Google built-in (ie. cars running Android Automotive with access to Google Play). Look for it on select Renault, Polestar, and Volvo cars.


* Vivaldi browser is now available for all cars with Google built-in. Download it from Google Play.

* You'll soon be able to download the Weather Channel app through Google Play on cars with Google built-in. The app will show hourly forecasts and feature follow-me alerting and a "Trip View" radar.

* Digital car key support is now rolling out on select Hyundai, Genesis, and Kia models in the U.S., Canada, and Korea for drivers with compatible Pixel and Samsung devices such as the Pixel 7 Pro and Galaxy S23+.

Google plans to let third-party apps read the measured battery state of health, ie. the remaining estimated full charge capacity relative to the rated capacity in %, in Android 15.

Currently, this value can't be queried through the public Android SDK, as it is gated by the system-only BATTERY_STATS permission (though as I discovered a few months back, this permission can actually be granted manually through ADB).

Android 14 introduced the API for reading the measured battery state of health, but it was restricted "not due to privacy but [due] to eng[ineering]" as there weren't any "usecases [sic] where an application would require this permission." However, it seems things have changed, as there are now use cases planned for it, so they're making it publicly accessible.

Note that even if Android 15 opens it up as a public API, the data likely won't be available on every device. It may be the case that the device's battery charging IC has to be set up to report this data to Android's health HAL, which in return is read by the OS and subsequently apps calling this API.

Physical keyboard support will soon get even better in Android.

Android (likely in an upcoming Android 14 QPR build) will soon show a preview in Settings when selecting a different physical keyboard layout. In addition, Android will also add an accessibility setting to toggle sticky keys.

Sticky keys, for those who don't know, make it easier to enter keyboard shortcuts in quick succession. When you press a modifier key like Ctrl or Alt with sticky keys enabled, it'll stay pressed so you don't have to hold it down while pressing other keys.

Samsung, to their credit, already added sticky keys support in One UI, but it's always nice to see AOSP/stock Android gain these features.

I don't have screenshots of Android's new physical keyboard layout preview or sticky keys toggle, but I know they're in the works thanks to this AOSP commit.

aconfig seems to be a new way to define feature flags at build time. It's similar to the DeviceConfig API, which lets Play Services remotely toggle flags, but aconfig also allows configuring flag values based on the build ID as well as setting certain flags to be read-only.

If you're wondering what other keyboard-related improvements Google has made in Android 14, as I first reported, the OS introduces features like touchpad gestures, modifier key remapping, expanded keyboard layout support, backlight input control, and more keyboard shortcuts.

Google has updated the "Phone Hub" support page to note that the Nothing Phone 1 and Nothing Phone 2 support streaming apps to Chromebooks!

Phone Hub refers to a suite of Android <--> Chrome OS cross-device features. In May, Google officially added app streaming to Phone Hub, enabling you to stream apps from select Android 13 devices to your Chromebook.

At launch, Google's support page said that app streaming was only supported on the Pixel 4a or later running Android 13, as well as the Xiaomi 12T, 12T Pro, 13, and 13 Pro running Android 13. However, I reported that the feature should expand beyond those devices, as it only requires 3 things:

1) The OEM needs to preload a stub for Google's Cross-Device Services app.

2) The build needs to declare the com.google.ambient_streaming feature to receive updates to Cross-Device Services.

3) The device needs to be running Android 13.

Currently, 73 device models declare the requisite feature, and many of them preload the Cross-Device Services app. The app is preloaded on my OnePlus 11 and ASUS Zenfone 10, though I haven't checked if app streaming works on them yet.

Let me know if app streaming to Chromebooks works on your device, especially if that device isn't officially listed on Google's support page yet!

Just shared 2 new posts for subscribers.

The first is pretty exciting: I heard that Google wants to make the camera experience in third-party apps better.

The second is about how Google is improving the security of the Android OS's software supply chain.

The first story will remain exclusive to Patrons/X subscribers, while the latter will go public for everyone on Monday.

Subscribe to read them now.

After 5 releases, Google is preparing to update the Dalvik Executable Format (DEX) in Android 15 "Vanilla Ice Cream".

DEX v41 is in the works for Android 15. The last version, DEX v40, was released with Android 10.

DEX files contain the compiled code of Android applications. If you've ever opened up an APK file, I'm sure you've seen those classes.dex files before.

With version 41 of the DEX format, Google plans to "allow multiple dex files within [a] single 'container' (either a zip entry or a plain on-disk dex file). This allows sharing of string (and other) dex data, since the offsets can point to shared data payload."

It's a little confusing how the patch talks about multiple dex when "multidex" is already a thing, but what seems to be happening is that currently, "multidex" refers to splitting compiled code into multiple different individual DEX files (classesN.dex) whereas the new "multidex" refers to putting multiple DEX files in a single container.

How DEX files work under-the-hood is not my forte, so I asked
Anestis Bechtsoudis, a security researcher and creator of multiple open source DEX-related tools, what they thought of this change and whether the 64K method reference limit will be addressed by this. Here's what they had to say:

"From what is [sic] looks like they introduce the concept of container that can host one or more dex files. The shared data section(s) of the container become sharable and this will allow external DEX files to reference them*. This is because their offsets are no longer relative but directly accessible from header.

From what is [sic] looks like they want to make some concept of dynamic loadable shared data to deduplicate event more (across different Apps / Services) common resources (to save disk space and memory when all frameworks are loaded).

Of course compact dex is no longer possible because you need relative offsets, thus they disabled it. But at any case it shouldn't be needed any more.

(1/2)