Random Musings on the Android 12 Beta 1

Each time Google releases a follow-on developer preview, I rummage through the incremental API differences report, the release notes, and even the release blog post, to see if there are things that warrant more attention from developers. I try to emphasize things that mainstream developers might use but may not get quite as much attention, because they are buried in the JavaDocs.

After a slight delay for the API differences report to be released, let’s peek at what we got in Beta 1!

(and many thanks to Wojtek for the help in getting that report!)

What Continues To Be Disappointing

The overall improvements to app widgets that I have been reporting on in past musings are great. But the mandatory rounded corners make me wonder if targetSdkVersion got deprecated or something. This is now the second UI change, after the splash screens, that can materially affect apps and cannot be postponed until developers have time to deal with it. Every app widget will have rounded corners, like it or not.

I can stomach mandatory immediate changes that affect privacy and security. But aesthetics? As one developer put it to me on Stack Overflow a decade ago, “if I wanted somebody to tell me what my app had to look like, I’d be writing for Apple”.

Wanting a standard launch UI and, um, roundy app widgets is perfectly reasonable for Google… but, please, give developers reasonable time to adapt.

What May Cause Your App to Show Up In Klingon

It appears that some devices — whose names might end in “ixel” — are going to be able to offer system-supplied translations of user-visible strings. This is almost completely undocumented, though there are many classes in a new android.view.translation package, plus related methods on View. You can also query PackageManager to see if the device supports FEATURE_TRANSLATION.

My questions are:

• Is this opt-in? Or is this like splash screens, and apps will get translated without developer consent?

• If this is mandatory, is Google going to supply the multilingual customer support needed for app developers to deal with questions in unsupported languages?

I like the concept, but this opens a big can of worms. Having this show up, undocumented, in Beta 1 is disturbing.

What Else Might Cause You Grief

I like the concept of app hibernation, which appears to boil down to “we press the ‘Force Stop’ button, so you don’t have to!”. However, the documentation mentions that ACTION_BOOT_COMPLETED will be sent to the app after it moves out of hibernation, which may break apps that assume that ACTION_BOOT_COMPLETED happens at boot time. This, at least, only kicks in with a targetSdkVersion of 30.

If you like your castles to be bouncy, you may run into some compatibility issues. Alas, at this point, due to the passage of time, it is probably not a good idea to have your castles be spongy instead.

What Security Improvements Make Me Happy

Approximate location seems like a blissfully simple solution.

AttributionSource seems interesting.

We can query for version information regarding the hardware keystore.

And a bullet on a slide in “What’s New in Google Play”, referring to “code transparency”, offers some hope with respect to my uncomfortable questions.

What Else I Am Looking Forward To

The new Bluetooth permissions greatly reduce the “fear factor” that needing ACCESS_FINE_LOCATION imposed on apps looking to talk to Bluetooth devices.

For developers maintaining alternative app stores, you can now perform silent app updates, if the user grants permission. Which, since that permission is normal (inexplicably), you should just get by having it in the manifest.

What Has Me Scratching My Head

The docs for “Extended file access support” state:

Additionally, the media URIs that are granted by createWriteRequest() now support the APIs in the File class. These APIs provide the ability to read, write, rename, and delete files.

But… Uri does not have the methods of File. If what this is trying to say is that developers should be reverse-engineering a filesystem path out of a Uri… well, that takes me from “scratching my head” to “pounding my head”.

Also, there is a new DataLoaderService, which seems to tie into the app installation process. The documentation is scant at best.

And, DevicePolicyManager now lets you control the “app streaming” policy. That is described as:

App streaming is when the device starts an app on a virtual display and sends a video stream of the app to nearby devices.

I am uncertain if this refers to Android Auto, scrcpy, Windows 10, or something else.

What Makes Me Giggle

Performance class sounds like we’re talking about car trim lines (“the silky-smooth screen, the two-speaker audio system, and the Corinthian leather back mark this phone as being truly ‘performance class’…”).

What Else Caught My Eye

Android 11’s package visibility changes apparently had a hole that is being closed.

TypedArray is now an AutoCloseable, which seems like a nice addition. Too bad Jetpack Compose means we will be using TypedArray a whole lot less…

We can now detect if the device network is connected to an automotive head unit. I’m not savvy enough with Android for Vehicles with 4+ Wheels to know if this is for Android Auto, Android Automotive, or something else. It probably is not for Otto.