Random Musings on the Android 14 Developer Preview 1

It’s that time again!

When Google releases a new developer preview, I rummage through the API differences report the high-level overviews, and even the release blog post, to see if there are things that warrant more attention from developers. I try to emphasize mainstream features that any developer might reasonably use, along with things that may not get quite as much attention, because they are buried in the JavaDocs.

What Might Make You Want to Wait

Apparently, you can only run your app once on Android 14 DP1 from Android Studio, and you then have to uninstall it. And the fix is going to be in a canary release of Studio, rather than a patch release on the current production version.

What Might Be Less “Orphan Black” and More “She-Hulk”

Mishaal Rahmann reports that Android 14 might support app cloning. Here, “app cloning” appears to mean that the user can set up an app to have multiple distinct sets of internal storage (e.g., getFilesDir() on Context). This can allow them to, say, use multiple logins for the same app, simply by switching which clone they run.

This may cause some compatibility problems, because some developers refuse to use methods like getFilesDir() and instead hardcode filesystem paths. That has not been reliable in many years. However, many app developers can get away with it, because the scenarios where the hardcoded path might not work are uncommon (e.g., multiple device profiles, work profiles). App cloning may add yet another scenario where those hardcoded paths are a problem, and some apps will wind up getting smashed.

FWIW, launchers might need to play along with this — see ACTION_PROFILE_ADDED.

What Might Get Photo Access In a Bigger Pickle

Mishaal also reports that Google may be unhappy with the rate of Photo Picker adoption, and that Google might shoehorn the Photo Picker into the permissions flow. I agree with the premise that this can improve privacy and security. However, this change does not appear to be documented, and it will be interesting what the impacts are from a compatibility standpoint.

What Else Screams “Compatibility Concerns”

There is quite the list of things that are documented that might break apps from unwary developers. Some of these will affect many current apps, such as:

• Broadcasts sometimes no longer being delivered when your app is running but is not in the foreground

• SCHEDULE_EXACT_ALARM no longer being granted by default

Others will crop up later in 2023, when you raise your targetSdkVersion to whatever the magic number will be for Android U:

• Mandatory foreground service types, complete with exceptions, and a veiled threat of the ban-hammer swinging freely on the Play Store for apps that fail to comply

• Blocking implicit Intent use even further

• Requiring registerReceiver() to specify if the receiver should be exported

Usually, there are some undocumented (or late-documented) compatibility challenges too.

What Would Matter If Device Manufacturers Were, Y’Know, Reasonable

There are new foreground service types, such as for health. It would be even nicer if these actually mattered, as device manufacturers routinely nerf your foreground service anyway.

There is a new data transfer type of Job. Maybe device manufacturers will pay attention to these and let them actually run.

What Makes Me Consider Using Jedi Mind Tricks

Android 14 has CredentialManager and CredentialProviderService and a bunch of other code tied to “credentials”. This appears to be in support of a Jetpack library for integrating traditional logins, passkeys, single-sign-on services, etc.

Ideally, this would be awesome. Google’s track record makes me less than interested, at least until this code gets seriously vetted. At least it is part of the AOSP — I would have expected this to be part of the closed-source Play Services SDK.

But, seriously: an OS that has an entire class hierarchy for ads doesn’t exactly strike me as the sort of OS where I want to be trusting the OS itself very much.

Note that View now has isCredential() and setIsCredential(), to flag UI elements tied to credentials. It is unclear what impact this has, though it would be nice if they were automatically redacted in screenshots.

What Might Be Signs of Competition

An app using PackageInstaller can now request enforcement of update ownership. In other words, if Store A installs an app and requests this, other stores will need permission from the user to update the app, even of those other stores hold INSTALL_PACKAGES and can otherwise freely install apps. This also can be requested in the manifest, apparently.

My guess is that the Play Store will apply this to everything it installs… but this implies that Google sees a future with more stores.

What Else Is Rich

setStyleShortcutsEnabled() on EditText apparently lets common hotkeys like Ctrl+B apply formatting. This is the first tiny step towards getting first-class rich-text editing in Android, which would be welcome, if the current support is limited to people using keyboards.

In somewhat related news, support for handwriting recognition seems improved, with several new methods on View and ViewConfiguration.

What We Might Be Allowed To Do

There are many new permissions. Of note:

• Each foreground service type now has its own associated permission, such as for access location data

• We might need a permission to turn the screen on

• They appear to be adding hooks to allow apps to find out when screenshots are taken, which would be a nice addition

• It is unclear how they define Wifi display, but it would be sweet if we somehow got Miracast support back

• Google Glass might be making a comeback

What Features Might We Require

There are a few new <uses-feature> elements we can add, including:

• Support for the aforementioned CredentialsManager, which implies that this will not be available on all devices

• Support for ultra wideband

• Support for seamless refresh rate switching

What Means We Can’t Have Nice Things

Another new <uses-feature> element is for “device lock” support. This probably ties to DeviceLockManager. The primary cited use case: a “financed device, where the financing entity has the capability to lock the device in case of a missed payment”.

The concept of having financed devices is fine. The concept that financers and and complicit device manufacturers can lock the device for non-payment is unsurprising. Having this “feature” baked into the OS is disturbing.

What I’m Surprised Took This Long

As a native English speaker, I am frequently unaware of all of the different nuances of other languages. But I am a bit surprised we made it this far without support for grammatical genders.

What Is Going… Going…

Criteria-based APIs on LocationManager are now deprecated.

What Else Intrigues Me

We can now, finally, figure out what other app started our app.

There is a VirtualDeviceManager. It is undocumented what this pertains to, other than probably not the Android SDK emulator. However, it also ties to the notion of creating a “device Context”. And, given this listener, this appears to be for moving an app to a different device, such as from your phone to the rumored tablet/hub thingy that Google is building.

More of Health Connect is baked into the OS now, with the addition of HealthConnectManager.

TextView can now have highlights. It is unclear how this related to the rendering of Spanned objects, which was our traditional way of highlighting certain portions of the text.

You can get the shape of a Display. It is unclear if this is designed for Wear OS or for other scenarios.

There are new types of KeyEvent, including for stylus buttons.

StrictMode can now complain if you manually request garbage collection.

As part of adding a few hundred OpenJDK 17 classes, we got StackWalker. I can see this being useful for diagnostic tools like LeakCanary.

The media projection APIs now support screenshots for a specific or user-selected Display.

Our existing runtime resource overlay (RRO) support is getting expanded with fabricated runtime resource overlay (FRRO) support.

There is an AltitudeConverter, hopefully not for Android-powered airplanes.

Android now supports Dvorak keyboards, though really the international keyboard types are more important.

We can now find out how much memory the user was told their device has, which might not resemble how much memory their device really has.

Apps on Chromebooks can now request to move to full-screen mode.

And, finally, we can now ask to create a note, even on the lock screen.