Android Developers Blog

Official announcement: https://android-developers.googleblog.com/2025/08/elevating-android-security.html

More info:

https://developer.android.com/developer-verification

https://support.google.com/googleplay/android-developer/answer/16471116

Personally...we all know the Play Store is chock full of malicious garbage, so the verification requirements there don't do jack to protect users. The way I see it, this is nothing but a power grab, a way for Google to kill apps like Revanced for good. They'll just find some bullshit reason to suspend your developer account if you do something they don't like.

Every time I hear mentions of "safety" from the folks at Google, I'm reminded that there's a hidden Internet permission on Android that can neuter 95% of malicious apps. But it's hidden, apparently because keeping users from using it to block ads on apps is of greater concern to Google than keeping people safe.

> we will be confirming who the developer is, not reviewing the content of their app or where it came from

This is such an odd statement. I mean, surely they have to be willing to review the contents of apps at some point (if only to suspend the accounts of developers who are actually producing malware), or else this whole affair does nothing but introduce friction.

TFA had me believing that bypassing the restriction might've been possible by disabling Play Protect, but that doesn't seem to be the case since there aren't any mentions of it in the official info we've…

> This entire comment is wildly misinformed.

As far as I can tell, you don't dispute a single statement in my comment.

> Are you forgetting Apple charges like $1200 for a phone these days?

This is a strawman. iPhone starts at $429 in the US, and there is no law saying companies can only monetize with up-front hardware costs. Such a law would be unprecedented in software.

> Are you suggesting that in order to cover the extensive research and development costs of music playback (sorry did you really say this?)

I didn't say that. I said mobile music playback. Streaming the world's music catalog to a mobile phone reliably with all-day battery life would be unthinkable 17 years ago, and the primary innovator making it happen was Apple, not Spotify. Core Media APIs are simply the tip of the iceberg, yet are widely recognized as best in class by a lot. Android took over a decade to catch up to iOS audio latency in 2013: https://android-developers.googleblog.com/2021/03/an-update-on-androids-audio-latency.html?m=1.

Remember when Spotify released their take on music playing hardware with Car Thing? They literally couldn't sell their first run of inventory and ended up taking a 8+ figure write down. That project probably cost Spotify more than they've paid Apple in fees in the last decade, yet the Spotify in-car experience is great because of CarPlay, an Apple technology!

> they need to take a 30% cut of every song played on the device?

I made no claims about how much Apple…

I am surprised at all of the app developer shaming in this thread. Is it really likely that every developer working on a popular BigCorp app is an idiot who imports 10MB libraries every time he/she faces the slightest challenge?

It's much more likely that app developers are optimizing for many things, including app size, but reducing app size has a bad cost/benefit ratio. Here are some decisions that may bloat your app:

* Want your network calls to be fast and reliable? Better use that cool new HTTP library rather than writing your own.

* Want to keep everything secure? Rule #1 of hacker news is never roll your own crypto so better import the best lib out there.

* Want to delight your users and their fancy QHD screens? Time to include some high res images and animations. Oh and you can't use vectors, they kill performance.

* Want to access new markets? Time to translate your strings into 80 common languages. Oh and some of these may require custom fonts to look right in your app.

* Want your Android game to have blazing fast graphics? Import that native library, and don't forget multiple architectures.

The biggest app I ever worked on was Google Santa Tracker. It was about 60MB. We spent a lot of time optimizing the app size in this year's version. We managed to drop 10MB while adding a few new games to the app. I'm proud of it, but if I didn't have the freedom to pursue app size I certainly would have taken the extra bloat to ship the new…

Google is bringing Java 8 support, and from what I understood from one of their engineers, they are working on supporting invokeDynamic as well, so we might get the whole package: https://android-developers.googleblog.com/2017/03/future-of-java-8-language-feature.html?m=1

Scala 2.12 has moved to Java 8 indeed, however this means modern features that are used for encoding Scala: invokeDynamic and default interface methods.

These should make Scala compiled code faster and more stable in regards to backwards compatibility. Both Java 6 and 7 have need EOLed. We cannot stand still because of Android's shitty support.

Google has effectively fractured the ecosystem, pulling off what Microsoft couldn't do with J#, and they got away with it. I actually think that they preferred to announce Kotlin as being a first class citizen as a marketing trick in order to offset the lack of support for Java 8.

Even so, Scala does in fact have great Android support:

1. Scala 2.11 will remain supported for some time, language-level features have already been backported from 2.12 and Typelevel.org also has a commitment to support it even further

2. We have great integration with the tool chain, see https://github.com/scala-android/sbt-android

3. For a pretty cool open source project made with Scala, that uses functional programming libraries like Cats and Monix, see: http://www.9cards.io

So if you think about it, given all the other tooling available, compared with other languages Scala…

Yup! This issue, which is commonly described as the "wrong-side-of-the-street" or "wrong-city-block" error, is one of the biggest ones, and is where a lot of the innovation I mentioned is happening today.

This occurs because in "urban canyons", meaning streets with tall high-rises or sky scrapers, there is little or no line of sight to GNSS satellites (GNSS being the generic term for all satellite positioning systems, not just the American GPS). Consequently, what your phone picks up are signals reflected off of buildings, which exaggerates the distance between you and the satellites, and causes the positioning solution to be pushed away- onto the other side of the street or another city block.

One way Google/Android is tackling this is by using Google's trove of 3D building data, the same that is rendered in Google Earth when you use it in 3D. Your phone uses the building data to correct for reflections. Read on here (and note the authour!): https://android-developers.googleblog.com/2020/12/improving-urban-gps-accuracy-for-your.html

And, the device can use various filters and smoothers to minimize sudden jumps, and normally does, but there are edge-cases (for example, an app may be requesting pure "unfiltered" GNSS location returned directly from the GNSS chipset, hence the jumps). But rest assured, we are working on this issue.

Anyway, thanks for the feedback. We're always doing our best to improve location accuracy and reliability for billions of users in all…

Having a library in the OS and actual interoperability are vastly different things. Not only do most consumer chat apps completely disregard HDR, but even worse, sending HDR images via almost any such channel has a high chance of the colours being mangled or -- at best -- silently converted to 8-bit SDR.

"Ultra HDR is amazing, but can be only viewed as such only on a Pixel phone. If I'm sending a pic to say FB Messenger it doesn't upload as Ultra HDR." https://www.reddit.com/r/GooglePixel/comments/17n0fkh/ultra_hdr/

Also, unlike Apple iPhone users, people with Android phones tend to get stuck on older major versions and can't upgrade. Easily half of all Android phones out in the wild can't correctly tone map or display either wide-gamut or HDR still images.

You mentioned Android 4 and 8, but full support for wide-gamut (Display P3 and Rec.2020) was only supported starting with Android 14: https://source.android.com/docs/core/camera/wide-gamut

Android 8.1 was the first version to introduce any display colour management at all, which was in late 2017: https://source.android.com/docs/core/display/color-mgmt

As recently as May 2019, there were Android developers blog articles with titled "Wide Color Photos Are Coming to Android": https://android-developers.googleblog.com/2019/05/wide-color-photos-are-coming-to-android.html

Similarly, mixed SDR and HDR content (i.e.: not just a full screen Netflix-style app) was supported only since Android 13:…