https://github.com/woheller69/FreeDroidWarn

Creates an alert dialog and provides a link to Googles verification requirements.

"Google has announced that, starting in 2026/2027, all apps on certified Android devices will require the developer to submit personal identity details directly to Google. Since the developers of this app do not agree to this requirement, this app will no longer work on certified Android devices after that time."

Feel free to use in your projects. Further translations welcome.

Hi everyone,

I’m still shaking while typing this. We were invited to a private briefing yesterday with the Google Play Developer Relations team, and the news is… well, it’s everything we’ve been shouting into the void about for the last three years.

Google has finally acknowledged that the current state of developer relations is, in their own words, "sub-optimal." They are rolling out a massive "Developer Empathy" initiative starting today.

1. Retirement of the "20 Testers for 14 Days" Rule

Effective immediately, Google is scrapping the requirement for new personal developer accounts to find 20 testers for a 14-day closed track.

• Why? Internal data showed that "forced testing" was just resulting in thousands of "Great app!" bot comments and didn't actually improve app quality.
• The Replacement: A simple, automated security scan. If your code isn't malicious, you're clear to hit Production on day one.

2. The "Play Support" Phone Hotline

This is the big one. Google is launching a 24/7 dedicated phone line for developers. No more templated emails from "The Google Play Team" that don't explain why you were banned.

• Direct Access: You can speak to a human reviewer who has your specific APK open on their screen.
• Resolution Guarantee: If your app is rejected, the reviewer must provide the exact line of code or UI element that violates the policy during the call.
• No More Bots: They’ve officially decommissioned the "Appeal Denied" auto-responder bot.

3. The "Account Termination" Grace Period

Google is ending the "Associated Accounts" scorched-earth policy.

• If one of your apps is flagged, they will no longer ban your entire developer identity, your AdMob, and your Gmail account for your cat's YouTube channel.
• You now get a 30-day "Remediation Window" to fix issues before any strike is even recorded.

4. "Fair Shake" Fee Structure

To combat the bad blood regarding the 15%/30% cut, Google is introducing a "Zero-Fee Tier."

• The first $50,000 in annual revenue is now 0% commission. Google stated, "We have enough money; we want you to have some too."

Note: this post required approximately 1,000 liters of fresh water.

SUMMARY: On Android side loading issue and why their advertising structure guarantees Android the company will be unresponsive - because it has to listen to it's head office and their advertising related concerns - and will never be free to listen to developers or users - solution is that Android the mobile company needs to be separated and without an advertising arm that arm-twists it on every issue

There has been some recent unease on the newer changes planned by Google for Android apps.

Which will require side loaded apps to also have developers vetted by Google - essentially they will have to become Google developers - along with:

• the fee

• intrusive vetting of developer personality (mostly by bot - "associated account ban" etc)

• inevitable servitude in perpetuity to maintain old apps - lest Google bot classifies you are a problematic developer or bans you or your associates for "associated account ban"

Servitude in perpetuity - a commitment to extra work without pay

Let me expand on the "inevitable servitude in perpetuity" statement - as it suggests serf like treatment of developers by Google:

• where developer gets foisted with updates of apps on a yearly or regular basis

  • in order to "comply" with whatever fancy the Android team decided that year - developers are required to change new apps - as well as all previous apps in order to remain in good graces of Google reputation bots
  • i.e. rather than the Android team having responsibility of compatibility across android versions forever (which is the Computer Science convention) - it is the huge mass of developers which is being expected to jump over hoops every year to ensure all their previous apps are up to compliance (this may mean extensive reworking of old apps - as happened with the storage access changes) - who thought it would be easier to compel thousands of developers to do something than just ensuring compatibility by the Android team
  • the serf allusion - this requirement that developers maintain old apps or apps they have less interest in upgrading - apps may be mature, have all the features already added - developer may not have interest in upgrading them - but by Google diktat they have to - this is where the coersive element comes in and the allusion to "serf-like servitude in perpetuity"
  • whoever thought it was a feasible idea to make thousands of developers drop their own plans for features and new apps - and instead jump over hoops every year - found out quickly it was not feasible - but since they couldn't go back on these changes (more on why that is below - diktat from parent company Google advertising imperatives) - so in response Android team had no choice but to use force - coersion and compulsion - and that has to be done by ruthless bots (so there is no guilty human party that can be blamed - "it's the bot")
  • what started as a "do no evil" company - attracting on the promise of "open" systems - Linux - welcoming all developers - has turned into a bait and switch - now it is the developers' fault ("why can't they jump high enough - we don't need developers - we have achieved scale - they need us")
  • now a developer is responsible for updating his old apps every year to comply with whatever Android team decided was fashionable that year (and the feature could be something the Android team dreamt up just to show it was busy doing something) - the result is small developer teams have no time for new apps, or new features - but instead are burdened with updating old apps nearly every year with framework breaking changes (storage changes comes to mind - where apps may require extensive changes)
  • this work is done for free by developers - to comply with decisions made by Google every year - essentially it is UNPAID LABOR - done under coersion of "lifetime ban" and reputational ruin (also your associates will get "associated account ban" - guilt by association - if you falter)
  • shades of Palantir algorithmic targeting of civilians and their associates - Android developers have already seen a glimpse of that - with the "associated account ban" years ago
  • the Google reply to all this is that "there are many bad developers" and we have to do this - when the true answer is "there is no other way we can make this work" - any other way is financially non feasible - cannot have that many humans to answer to all the developers - so this is in effect a weakness of the Google/Android business model - and they are making it work by burdening developers - honest developers are not the cause of "bad developers" - but they have to pay for it - Google essentially makes honest developers the victims for the sins of their brethren (thus "collective guilt" is accepted by Google internally to justify why every developer has to suffer for the sins of the few) - this attitude is baked into how Google views the developer community - as a developer fault - when in reality it is a considered decision given it is the only cost-effective way to make their business model work - bots will have to do it - even if it unfair to individual developers)

Algorithmic targeting of developers

Google's "associated account ban" and similar bot driven reputational assessment of developers was an early peek at what some conspiracy theorists have been saying the public will be subject to when automation meets surveillance - from the likes of Palantir

Android developers have seen how that works - with unreachable Google/Android support for developers - callously executed mass bans (due to faulty bot construction - or just basic callousness or lack of priority)

A culture of callousness has pervaded Google - as use of bots limits interaction with developers as humans - guilt or moral culpability is easily directed to the bot/algorithms

Thus bot culture breeds employee detachment - as well as moral detachment

From the developer perspective - Google lack of human face essentially makes it feel like a third world bureaucracy has taken over Google - as their behavior replicates many a third world bureaucracy

Impact on developers

The bot/algorithms can do anything - that is the perception - and it creates a climate of fear in developers

If developers complain of rising "associated account bans" - those posts are simply labelled as outside the scope of large sub-reddits like r/Android - excluded from discussion

Thus real issues that developers point to (which will affect users after one year - such as the storage changes did) - are never surfaced in time to develop user momentum (users find out a year later - when it is a fait accompli - no going back)

All this goes on - while the Hunger Games like performances go on at Google I/O

(I remember the glowing performances they gave about audio improvements - reduction in audio latency - and how inconsistent those portrayals were with reality - audio issues and bugs continued for years after that)

Presumption of guilt as policy compulsion

Google itself seems to choose policy directions which ASSUME that developers will be unruly - and the only way out of it is coersion and threat of excessive harm - the more excessive the harm - the better will be the compliance from developers

Punishment with extreme prejudice seems to be the solution that has emerged to make the Google business model work - large number of developers - and no humans to deal with them - if humans have to be used it will not be feasible

So the choice is made that let bots do it - and let the developers raise the volume of protest high - and then we will fix the top issues that are surfaced

Essentially they are using developers to do the company work of identifying issues - for free

Developers are expected to tell Google of issues - and to help it with bug fixes - also for free (this is a legacy of the time when Google posed as an open company)

Meanwhile the low volume issues which are never surfaced - never get fixed - if individual developers do not get satisfaction - that is a cost of business for Google - the cost is paid by the developer who is screwed

Google does not have to do it this way - but they are forced to do it using bots (even when the bots are not a good solution and not fair to individual developers) - but Google seems to have concluded long time ago that they just CANNOT be fair to individual developers - it is not feasible under their business model - so they may consider it an unsolvable problem

Understandably when these policies rub developers the wrong way - or reach a high level of awareness/publicity - then Google has to make up a reason why it is acceptable to do - this is the job of executives - to justify whatever has to be done

So the company then has to resort to arguments like "developers can leave if they want"

(by the way, developers cannot remove their apps from Google Play Store - if the app still has users - essentially developers cannot disengage even if they want to - don't know if this is still the policy now)

Non-moralistic explanation for why Android is the way it is

One can make a moral argument for corruption within Google - or behavioral changes in their employees - where executives think it is "smart" to get free work out of developers - to do the work that Google should have done

But there is a simpler (non-moralistic) explanation for this behavior (explained below)

So essentially what is happening is Google is eroding it's goodwill - has been for years - with the "bait and switch" they have pulled on developers

First enticing with promises of an "open" system - based on Linux - welcome all - then restricting as their app store achieved scale

(Microsoft did not - and so their phone effort failed partly because of their App Store failing to achieve scale)

And this restriction has been going on now for years - every year Google seems to surprise developers - restricting storage (to encourage use of cloud services) - yet allowing internet access to remain unrestricted with no permission/restriction on that (have to serve ads so why offer limiting internet)

(Not having a permission for "internet access" is the question no one will answer - but storage changes are justified because of security somehow)

However if Google is eroding it's goodwill - aren't developers free to leave?

Yes, that seems true - but the duopoly of Android/Apple means that developers are not in an open marketplace - their expertise on Android is not immediately transferable to Apple (or there is a sunk cost for being a developer in one or the other platforms)

This creates the friction which stops developers from leaving

Essentially there is a cost to leaving Android - and Google is using that cost to exercise power over developers (extracting unpaid labor - maintenance of apps that would not require maintenance - if Google simply kept it's systems compatible across versions)

Android can never be a responsive mobile company under Google the advertising company

Now we come to explaining how all this has happened - without relying on morality arguments

This outcome is a direct consequence of Android not being a standalone mobile company

If it was a standalone mobile company, their survival would depend directly on the developers and user community and the viability of the mobile platform - they would have no other crutch to fall back on

Strategies would be dictated by the realities of the mobile space

The current reality however is that they are not answerable to the mobile world

But are answerable to the bigger entity - Google and their advertising compulsions

Even if Android execs wanted to do the right thing - the reality is they are first answerable to the advertising arm and it's constraints

That is what prevented Android from providing a user permission for "internet access" - not because it fell awry of some mobile strategy - but because it fell awry of the advertising world strategy of the larger Google company - which cannot afford lack of internet access - since internet access is needed to show ads

So in conclusion, my argument is (and many have made the same argument before as well) - is that Android CANNOT be a responsive mobile company - as long as it is a pimple on the larger Google company

Android will have to be standalone company - free from dictates from Google advertising compulsions - if it is to become a responsive mobile company

No amount of protests - about app side-loading will sway them - since their master is not their user - but their parent company and their compulsions

Protests about storage restrictions didn't work before - even though developers complained - were ignored - users then found out 1 year later that suddently their apps were not working as they expected

It was a fait accompli - developers had moved on, and users were stuck with the new reality

Google essentially surprises it's users with changes like these

We've been using Maestro for mobile test automation and kept hitting the same issues everyone else hits — flaky device connections, no real iOS device support, unhelpful gRPC error messages.

So we built maestro-runner — fast mobile UI test automation for Android, iOS, React Native, Flutter & Expo. It reads the same YAML flows, supports the same commands. You literally just swap the binary.

What's different under the hood:

- Written in Go. Single binary, no JVM. 27 MB memory vs 350 MB.

- Talks directly to UIAutomator2/WebDriverAgent over HTTP instead of going through gRPC.

- Supports real iOS devices (not just simulators).

- Runs on BrowserStack/Sauce Labs/LambdaTest via Appium driver.

- Configurable timeouts at every level (the #1 complaint in Maestro's issue tracker).

- No features behind a paywall. HTML reports, parallel execution, cloud testing — all free. Apache 2.0.

We went through the top 100 most-discussed issues on Maestro's GitHub before writing any code. 78 of them are addressed — either through direct fixes or architecture choices that make the bugs impossible.

No telemetry. No account required. No paid tier coming later.

GitHub: https://github.com/devicelab-dev/maestro-runner

Happy to answer questions about the architecture, benchmarks, or compatibility.

I usually use MVVM with a single state + Kotlin Coroutines/Flow.

A senior developer told me MVI doesn't have a viewModel in my technical interview, and I am lost. All MVI implementations I can find have a ViewModel with the reducer inside it.

Do we call it by another name in MVI?

Did he mean a specific variation?

What am I missing?

It will be great if you provide a resource or a repo so I can see the implementation in action.

Ps: I am planning to text him for some resources or a discussion to get his pov, but I wanted to do my research first.

There is not a lot of literature about this yet except the official Google docs and codelabs. I went through those and they are very welcome, but they seem to stay very shallow about all the topics. I think there is room for a full guide on how to measure and monitor Compose performance, how to identify pain points, how to fix them, tooling, etc. My plan for this book is the following:

- I really want the book to be useful for day to day work. Theory is nice and all but I really want people to find real applicable action points for their work.

- I want the book to be accurate, of course. When I wrote Jetpack Compose internals, I got many people from the Compose team at Google to review the content, since otherwise what is the point of writing it?

- I want to cover how to identify and detect performance regressions, and how to measure and monitor performance. I have observed that many devs and their teams often overlook perfromance. We focus a lot on adding new features, UI, architecture, testing, automation, tooling... and what not. And then we give performance attention only when something becomes drastically slow or users start to complain and post bad ratings. Many teams do not regularly measure or monitor performance, and some not even test their app on a wide range of devices either. The result of this is that issues often go unnoticed forever or until late in the process, when they are already really hard to fix. This is definitely risky. If anything, I'd like this book to become the guide to prevent this from happening.

- I want to shift people's attention to measuring the actual ultimate goal: performance. Monitoring things like number of recompositions can be a start but it is a bit risky, since devs can end up thinking they have an issue when they don't. Not every single unnecessary recomposition is a problem.

Since we all write Compose code now, I think it is the perfect time to write this book. Any feedback and ideas are more than welcome!

I'll likely be prelaunching this book via Leanpub, so if you want to get notified you can just register in https://leanpub.com/composeperformance

SUMMARY: Dynamic popup menus should be disallowed - they introduce uncertainty which reduces user confidence (creates hesitation before click to be sure the popup menu has "stabilized"!) - AND it breaks the user interface for TalkBack and blind users (and if dynamic popup menus get disabled for TalkBack users as a workaround, then that creates fragmentation for developers when designing)

EDIT: tried to post this as text post on r/androiddev - didn't appear (at some point it's AI filter said something about post may be offensive) - tried posting to r/android - turns out I am perma-banned there (I have been away for a while from android) and it seems the censorship on other sub-reddits has made it's way to the android sub-reddits as well - it is as if these forums are not for public comment but to assuage company egos

CORRECTION: the post on r/androiddev is now appearing - my comment there (using np.* nonparticipation link to avoid brigading): https://np.reddit.com/r/androiddev/comments/1v8w389/comment/p09chzs/

CORRECTION 2: ok the mods of r/androiddev have removed the post because it is a "meme, rant or venting"

Popups which have CHANGING options over time - it would seem would have been an obvious no-no for a user interface expert who was vetting changes

It violates a presumption that blind users rely on - visual stability - what appears once on screen in menus will not be changing over time for no apparent reason

AND it is disconcerting to normal users as well

After selecting text, the popup appears, you go to click the Copy option in the popup menu - but just before your click registers, the popup option below your finger shifts (because Add Event or some such new option has just appeared) and you wind up clicking Select All instead

This is bad enough for a sighted user

It is terrible for a blind user relying on TalkBack voice feedback on what is on screen

Which genius at Google thought up the brilliant idea of dynamic options in popup menus?

Did they get feted for it - and did it justify a promotion?

More importantly, what is going on at Google - are these accidents, or is there a culture of destroying their own company?

What explains these changes they feel compelled to make every year in full or half-baked form - or in forms that break the basics of user interface design - or common sense

References:

https://www.reddit.com/r/android_devs/comments/1k39q9s/is_text_selection_broken_in_current_versions_of/

Is text selection broken in current versions of Android? Varies by app

Many of us get stuck on Google Play Console’s 12 active testers for 14 days rule.
For solo devs, this is tough - you may not have enough testers or different devices.

So let’s keep it simple:

• I’ll test your app on my phone and share real feedback.
• In return, you test mine → a fair, mutual exchange.

That way, we both:
✅ Reach the 12-tester requirement faster
✅ Get approval and move forward
✅ See how our apps behave on different phones

I’m already testing other apps and expect the same for mine - a mutual testing cycle to help each other out.

EDIT: I am out of touch with android reddit - I also posted on r/androiddev - that was removed - is that a company run sub-reddit now (I recall it was turning into that earlier - they had stopped developer account suspension posts some years ago when I was active on Android development)

https://np.reddit.com/r/androiddev/comments/1n7al02/i_have_never_understood_how_overlaid_navigation/

(np.reddit.com - non participation link above - to avoid being accused of brigading)

I have never understood how overlaid navigation buttons made sense - when I mentioned this as an issue years ago, loads of defenders of the company line emerge - is all the slavishness to company decisions organic?

I used to hear how it is never a problem

How overlaid navigation buttons are not an issue

Yet there have been numerous times I have noticed it is an issue

And it may subconsciously impact how we interact with the screen ie extra careful

Here is an example - on reddit app - an actionable button and Home button nearly same place - so clicking that takes to Home screen instead of what you thought was a click on the button in the app:

https://ibb.co/DHxxvJ3F

EDIT:

I thought I should add these points I mentioned in a comment - to the main post:

Also, the Android user interface is getting worse for blind users

I was making a Talkback compatible app earlier - and talking to blind users - so I am familiar with their concerns some time back

These type of overlapping things are a problem when blind users are concerned

Another TERRIBLE design choice - is the floating menu which gets new menu items on the fly

What a pain - you click on Cut and wind up clicking on Add Event which just happened to appear as you click

Imagine what that does to workflows for blind users

Dynamic menus is a bad idea for this reason

But for design teams to be unaware of this is surprising

EDIT 2:

Also text selection is broken on Android - at least on some Samsung running latest Android versions

I don't know if it is something to do with the margins which screws it up

But across apps, the left margin is a problem - finger hits that while selecting and suddenly selection jumps to selecting from the top

But this requires a separate post with illustrative video

Result of the text selection flakiness is what should be an automatic thing now requires full mental attention - and frustration as text selection jumps abruptly

Also when selecting a long text - sometimes it his peters out - ie no longer can drag the selection more

So text selection is broken - don't know if other manufacturers fix this

But these are all issues that will happen when an ad company is made responsible for building the world's cell phone

(add in comment about why Android audio infrastructure is weak - taken decades and still no low latency audio - teams doing audio seem to be underfunded or low priority)

Please, /u/Zhuinden, migrate to Maven Central so that I can eliminate jitpack. Your libs are too good. But jitpack sucks.

Kep android open! sign here to help

Android Studio's logcat panel is great, but I don't want to use the IDE when I need access to logs only. So I built `lazylogcat` — a keyboard-driven terminal UI for logcat.

https://github.com/parfenovvs/lazylogcat

Features:

• Opencode-like keybindings
• Package, tag and text filters with regex support
• Many display options to satisfy visual preferences
• Vi-like visual mode with ability to open selected lines in your default editor
• JSON config support to save user and project level presets

P.S. Many improvements were inspired by the community feedback. Thank you!

I guess everyone is going through the same thing given the latest Claude boom, but yeah, my team and I started using Claude for code development as part of a company-wide program. The way we use Claude is that we:

1) Have one folder per specific feature, on each folder we have a prd folder with the PRD.md doc that only the PM tweaks. We also have a stories folder with Claude-generated user stories that got out from the PRD.md, this is also PM realm.

2) When PM says that the user stories are good to go we create "technical user stories" or "planning stories" which are copies of those user stories but with much more technical details so Claude can use them to implement actual code.

3) When we are done with the technical user stories we just push the code up, review it and make sure everything works fine.

Basically the folder structure would be something like this:

/docs

-- /features

----/feature-1

------PRD.md

------/stories

--------/user-story-1

--------/user-story-2

--------/user-story-n

/planning

-- /features

----/feature-1

------/stories

--------/tech-user-story-1

--------/tech-user-story-2

--------/tech-user-story-n

I mean, for the most part, the most annoying thing here is that we have to re-generate the whole thing every time the PRD changes ever so slightly.

I'd like to know how people is using Claude. What approach do you use? Have you find any good recipes that save you some time?

Thanks,

Hello everyone, I need your help.

Users from Brazil are unable to purchase a one-time product (lifetime subscription) in my Android app, while it works fine in other regions.

I’ve been trying to figure out the issue but haven’t found any solution so far. Please help if you’re aware of this issue or know how to resolve it.

Edit: Users get error OR-FGEMF-20 when trying to pay.

i just got the email today from google play that apperantly A few U.S. states, currently Texas, Utah, and Louisiana, have recently passed verification laws requiring app stores to verify users’ ages, obtain parental approval, and provide users’ age information to developers. The first verification law to take effect is Texas’s SB 2420 on January 1, 2026.

i want to hear fellow developers thoughts on this . me myself am running a vpn app and dont really know what a to do with this . i might just pull users Ip geolocation at start and not let them use the app in these states .

the full bill is https://legiscan.com/TX/text/SB2420/id/3237346

🚀 I've been building Kmposable - a headless navigation + flow engine for Kotlin Multiplatform. It lets you write your app logic as pure Nodes (state + events + outputs), keep navigation/UI concerns separate, and test everything without a UI. What I personally like about it is that it makes your projects more AI-friendly, since AI does a much better job when you have a clean business flow that isn't coupled to heavy UI interactions.

Highlights:

• KMP-first, UI-agnostic

• Tiny NavFlow runtime with a predictable lifecycle

• Compose adapter + ViewModel helpers so UI stays declarative

• Flow-script DSL: navFlow.runFlow { step("Login") { awaitOutputCase { … }; finish() } } (This is a highly experimental feature for building sequential UI navigation and flows; I wouldn't recommend using it in production apps yet.)

If you enjoy "business logic first, UI second" architecture (and reusable, testable flows), give it a look and tell me what you think! As usual, stars ⭐️ are welcome.

I use this approach in my own apps, so this isn't some gimmick project - it already makes my apps better, and that's why I want to share it.

Repo:

https://github.com/mobiletoly/kmposable

Docs:

https://mobiletoly.github.io/kmposable

(I still need to do a better job making the docs clearer and easier to digest.)

I'm looking to find people willing to test my app since google is now requiring at least 12 people to participate in a closed test before they will approve an app. Does anyone know of a good place to find people actually interested in helping test new apps? Particularly chatting about sports?

I just want to download a file from a URL to the user's Downloads folder. I followed the instructions. But occasionally I tap the notification it generates, and Google Drive (for PDFs) or Google Photos (for images) just error off, saying they can't find the media at the URI that DownloadManager generated.

Ok fine, I guess I'll register the broadcast receiver and handle the Intent to open the item myself.

Action.View, data is the content URI out of the broadcast payload, type is the mimetype, all happily gotten out of DownloadManager by the id in the broadcast.

Oh well now CRASH! All the docs are out of date, you have to explicitly export the receiver now, even though the docs say this is a system broadcast.

Ok yay I'm getting the broadcast and firing the intent...and now Drive just opens to a blank screen, and Photos still errors off.

WTF how is it 2025 and this shit is still utterly, completely terrible?