This wave’s brand-new artifacts includes a tie between Nav3 and Material3; broader multiplatform
support for androidx.compose.runtime:runtime-saveable, androidx.navigation3:navigation3-runtime,
and androidx.paging:paging-compose; plus a new android.text group:
androidx.compose.material3.adaptive:adaptive-navigation3androidx.compose.material3.adaptive:adaptive-navigation3-androidandroidx.compose.runtime:runtime-saveable-iosarm64androidx.compose.runtime:runtime-saveable-iossimulatorarm64androidx.compose.runtime:runtime-saveable-iosx64androidx.compose.runtime:runtime-saveable-jsandroidx.compose.runtime:runtime-saveable-linuxarm64androidx.compose.runtime:runtime-saveable-linuxx64androidx.compose.runtime:runtime-saveable-macosarm64androidx.compose.runtime:runtime-saveable-macosx64androidx.compose.runtime:runtime-saveable-mingwx64androidx.compose.runtime:runtime-saveable-tvosarm64androidx.compose.runtime:runtime-saveable-tvossimulatorarm64androidx.compose.runtime:runtime-saveable-tvosx64androidx.compose.runtime:runtime-saveable-wasm-jsandroidx.compose.runtime:runtime-saveable-watchosarm32androidx.compose.runtime:runtime-saveable-watchosarm64androidx.compose.runtime:runtime-saveable-watchosdevicearm64androidx.compose.runtime:runtime-saveable-watchossimulatorarm64androidx.compose.runtime:runtime-saveable-watchosx64androidx.navigation3:navigation3-runtime-desktopandroidx.navigation3:navigation3-runtime-iosarm64androidx.navigation3:navigation3-runtime-iossimulatorarm64androidx.navigation3:navigation3-runtime-iosx64androidx.navigation3:navigation3-runtime-jsandroidx.navigation3:navigation3-runtime-linuxarm64androidx.navigation3:navigation3-runtime-linuxx64androidx.navigation3:navigation3-runtime-macosarm64androidx.navigation3:navigation3-runtime-macosx64androidx.navigation3:navigation3-runtime-mingwx64androidx.navigation3:navigation3-runtime-tvosarm64androidx.navigation3:navigation3-runtime-tvossimulatorarm64androidx.navigation3:navigation3-runtime-tvosx64androidx.navigation3:navigation3-runtime-wasm-jsandroidx.navigation3:navigation3-runtime-watchosarm32androidx.navigation3:navigation3-runtime-watchosarm64androidx.navigation3:navigation3-runtime-watchosdevicearm64androidx.navigation3:navigation3-runtime-watchossimulatorarm64androidx.navigation3:navigation3-runtime-watchosx64androidx.paging:paging-common-desktopandroidx.paging:paging-compose-desktopandroidx.paging:paging-compose-iosarm64androidx.paging:paging-compose-iossimulatorarm64androidx.paging:paging-compose-iosx64androidx.paging:paging-compose-jsandroidx.paging:paging-compose-linuxarm64androidx.paging:paging-compose-linuxx64androidx.paging:paging-compose-macosarm64androidx.paging:paging-compose-macosx64androidx.paging:paging-compose-mingwx64androidx.paging:paging-compose-tvosarm64androidx.paging:paging-compose-tvossimulatorarm64androidx.paging:paging-compose-tvosx64androidx.paging:paging-compose-wasm-jsandroidx.paging:paging-compose-watchosarm32androidx.paging:paging-compose-watchosarm64androidx.paging:paging-compose-watchosdevicearm64androidx.paging:paging-compose-watchossimulatorarm64androidx.paging:paging-compose-watchosx64androidx.paging:paging-testing-jsandroidx.paging:paging-testing-mingwx64androidx.paging:paging-testing-wasm-jsandroidx.text:text-vertical
The full list of over 1000 updated artifacts can be found here.
—Aug 27, 2025
ICEBlock “is an innovative, completely anonymous crowdsourced platform that allows users to report Immigration and Customs Enforcement (ICE) activity with just two taps on their phone.”
The developer of ICEBlock disclosed his identity. In addition to receiving threats of federal prosecution over the app, the developer has faced other backlash, including
his wife being fired from a federal government job.
This is one recent example demonstrating that app developer anonymity has impacts and that the lack of such anonymity can cause harm.
With that example in mind, and in the spirit of a previous issue, I have some questions with regards to their proposed
developer verification program. To Google, these questions might be uncomfortable.
Question 1. What considerations were taken into account with regards to developers with legitimate reasons for anonymity?
For example, suppose that a developer creates an ICEBlock-like app, but one that supports
Android, which ICEBlock does not. Let’s call this workalike app “ICE Scream”. Given the experiences of ICEBlock’s developer, the developer of ICE Scream may have concerns over their identity being disclosed. How would Google like to address such scenarios?
Question 2. Which civil society organizations (e.g., EFF and AccessNow in the US) did Google engage with to review your plans, and what were the results of those engagements?
Organizations such as these have a long track record of dealing with the balance of equities related to privacy and security. A theoretical developer of “ICE Scream” would be well-advised to try reaching out (anonymously) to such organizations for advice. Similarly, their expertise and outside opinions should be of value to Google while drafting programs such as developer verification, and so one hopes that Google availed themselves of such assistance. How did that go?
Question 3. Why does Google’s privacy policy allow Google to share “personal information” with any “businesses or persons”?
Google’s privacy policy states that it provides “personal information to [Google’s] affiliates and other trusted businesses or persons to process it for us”, with no obvious restrictions on who or what constitutes “trusted businesses or persons” and no obvious restrictions on what those parties can do with the personal information. How does Google wish developers, such as the ICE Scream developer, to interpret that policy?
Question 4. How will apps be developed starting in 2027, as app development uses debug keystores, and those keystores do not seem to be part of the Android Developer Verification process? Will it no longer be possible to test apps under development on Google-certified production hardware?
Debug keystores are designed to be transient, as there are few repercussions from replacing those keystores as needed. As such, debug keystores can come and go, especially in environments like classrooms and continuous integration (CI) servers. It seems unrealistic to have these all be registered on a Google-supplied Web site, and it seems hostile to require anyone who wants to learn Android app development to file “papers, please”. How does Google wish for this to work?
Question 5. Similarly, how will apps be developed starting in 2027, as app development often uses duplicate package names (e.g., in educational settings), and duplicate package names are banned? For example, how will developers be able to build and run Google’s own sample projects?
I have a particular interest here, as I am the author of many books on Android app development. I expected readers to be able to download and run the samples, but under this program, it seems like at most one person on the entire planet can do that. Everybody else will get error messages until they go in and change the package name… which will be beyond the skills of many people just learning Android app development. How does Google wish for this to work?
If you have your own questions and concerns, in addition to writing blog posts, you can fill out and submit this form.
If any civil society organizations or others are interested in discussing these and related questions, please reach out!.
And, heck, if Google itself would like to talk about this,
they too can reach out.
—Aug 26, 2025
Apparently, the mid-cycle update will be under the “QPR” brand, so we got a beta for
it. We did not get a developer preview AFAIK, and it is unclear if there will
be any follow-on betas, despite the “1” nomenclature. 🤷🏻
So, given
the announcement blog post
and
the API differences report,
let’s see what we are in store for.
What Might Get Google Sued
According to the blog post:
Android 16 QPR2 can automatically generate a themed icon for your app if you don’t provide a dedicated one. The system applies a color filtering algorithm to your existing launcher icon to render it in a monochrome style, allowing it to integrate with the user’s chosen theme.
Given that some firms have a lot invested in particular colors, one imagines that there
will be some disputes over Google’s unilateral decision to replace those colors because
Googlers feel like it.
What Else is Scary
The new CAPTURE_KEYBOARD permission
“Allows an application to be able to capture keys before Android system get chance to process system keys and shortcuts.”
However, this is a normal permission, which means apps can request it and users are not
involved. Depending on the scope of this “capture” of keyboard events, a permission like this
should be dangerous at minimum.
What Might Break Your App
The system-generated dark theme outlined in the blog post
might work some of the time but feels like it is unlikely
to work all of the time. If you do not already implement a dark theme — one recognized
by the system — you might wish to test this behavior.
The changes to MediaRouter outlined in the blog post might cause you to need to request
more permissions, such as BLUETOOTH_SCAN, that you have not needed previously.
There is a “camera compatibility treatment for fixed-orientation apps”
that you can opt out of.
If you use the camera, pay attention to this.
What Requires Research
Launcher implementations should look into startVisibilityTracking()
and
stopVisibilityTracking()
on AppWidgetHostView. These will help trigger AppWidgetEvents for when the app widget
can and cannot be seen by the user, for metrics and whatnot. App widget developers can
use queryAppWidgetEvents()
on AppWidgetManager to find out about those events.
Launcher implementations ought to consider also researching the new
ACCESS_LAUNCHER_DATA permission.
Notification now offers isRequestPromotedOngoing() and Notification.Builder has
setRequestPromotedOngoing(),
for whatever “promoted ongoing notifications” are.
What Points Towards “Android on the Desktop”
The blog post describes “Display Topology API”, “Device-aware ViewConfiguration”, “Controlled Mouse Scrolling”,
“Files Desktop UX”, and a variety of printer API updates. While not completely irrelevant
for phones or tablets, this all points to a bigger push for Android on the desktop, perhaps
as part of the Chrome OS changes.
What’s Next?
The timeline in the blog post suggests two more betas, but it is unclear to what extent
they will introduce more changes, revert some of this release’s changes, or otherwise
affect us.
—Aug 23, 2025
