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.,
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
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 —
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
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
Intentuse even further
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
Maybe device manufacturers will pay attention to these and let them actually run.
What Makes Me Consider Using Jedi Mind Tricks
Android 14 has
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.
View now has
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
INSTALL_PACKAGES and can otherwise freely install apps. This also can
be requested in the manifest,
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
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
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
<uses-feature> element is for “device lock” support. This probably
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…
LocationManager are now deprecated.
What Else Intrigues Me
We can now, finally, figure out what other app started our app.
There is a
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
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
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
It is unclear if this is designed for Wear OS or for other scenarios.
There are new types of
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
I can see this being useful for diagnostic tools like LeakCanary.
The media projection APIs now support
screenshots for a specific or user-selected
Our existing runtime resource overlay (RRO) support is getting expanded with fabricated runtime resource overlay (FRRO) support.
There is an
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.