Random Musings on Android 11 Beta 1

Each time Google releases a new developer preview or beta, I read what I can to see if there are things that warrant more attention from developers, based on the API differences report and other release documentation.

Yesterday, Google released Android 11 Beta 1.

What I Liked a Lot

It shipped.

Build.VERSION_CODES.R now has the real value of 30, and we should be able to start using that number for things like targetSdkVersion in our projects.

Very little changed in the API from DP4, based on the API differences report.

And, they dropped Maps V1 from the firmware.

What Got Buried in the API Differences Report

Previously, Google added auto-resetting permissions to Android R. Basically, if the user isn’t using your app anymore, Android will revoke any granted runtime permissions. This is a perfectly reasonable feature.

However, there are a few apps for which this approach will be a problem, particularly in the personal security space. They documented a way to direct the user to a Settings screen where they can opt out of this behavior.

What Google didn’t document very well is that there is a new manifest attribute, autoRevokePermissions, that allows apps to state whether their permissions can be revoked this way. The documentation does not state where this attribute goes, but it probably goes on either <application> or the root <manifest> element. There are three documented values for autoRevokePermissions:

• allowed, which presumably is the default

• discouraged, which should allow the app to use a different Intent action to request to opt-out of this auto-reset behavior

• disallowed, which turns that opt-out into an opt-in behavior, so the user would have to take steps to turn on the auto-reset behavior

Note that the documentation for disallowed states that “This declaration may cause an additional review when publishing your app”. Expect forms to fill out if you wish to use that setting, and expect to get banned anyway by some poorly-written compliance bot.

Note that you can determine what the behavior is for your app by calling isAutoRevokeWhitelisted() on PackageManager.

What Is Disappointing

Past developer previews had APIs for device controls and media controls, but there was no documentation for them. There is a decent chance that one or both of these have bugs, because many things in a developer preview have bugs. However, that lack of documentation will have suppressed some of the testing that developers do, which means that it is more likely that those bugs will make it into production. And, if the “bugs” are really with the nature of the API, those bugs will endure forever.

Worse, past developer previews had APIs for an “inline suggestions UI”. That maps to “Consolidated keyboard suggestions let Autofill apps and Input Method Editors (IMEs) securely offer context-specific entities and strings directly in an IME’s suggestion strip, where they are most convenient for users.” in the release blog post. Autofill has security flaws that I wrote about when Android 8.0 shipped. Worse, since Google never fixed the flaws, autofill implementations were open for attack. Now, even more code gets to interoperate with autofill, and security experts have even less time to test that before release, because it is still largely undocumented.

What’s Next?

I will aim to have an update to Elements of Android R out in the next few weeks, updated for Beta 1.