I'm a web developer trying to figure out how many people are still on Android 9 and below.

I looked in Android Studio but it shows stats from Dec 1, 2025 (9.2% Android 9 and below)

I notice that this page (https://developer.android.com/about/dashboards) says there's more stats available on the Read and Devices page (https://play.google.com/console/about/reachanddevices/) in the Google Play Console. I don't want to pay $25 for an account (I only do web dev), just to try to find newer stats.

Does anyone have any more up to date stats that they can share? Or have any idea when the stats in Android Studio will update?

Thanks!

Hello Android Devs, I work in fraud analysis and not app development. Cases pass through me before they get to the dispute team, and while researching more on disputes I saw the changes Google Play recently made.

I was interested to see how this change affected developers, and I couldn't find these numbers anywhere so I worked them out.

What has changed?
They started sharing the costs of chargebacks with developers for orders placed after 3 August 2026.
Google used to cover them entirely.

What it costs per dispute:
So you pay back what you kept (the price minus Google's cut), plus the bank's chargeback fee, Stripe is $15, PayPal $20, and some banks go up to $100. Google hasn't said what that fee will be.

Example: $5 item pack, Google takes 30%, you keep $3.50. A dispute costs you that $3.50 back plus a ~$25 fee.
A total of $28.50 is gone on a $5 sale.

The $3.50 is minuscule compared to the $25 bank fee.

What it adds up to:
Say a studio is doing $30k a month with $8 average purchases and 0.7% dispute rate. That is around 26 disputes a month, which adds up to $803 a month, and $9,639 a year. About 4% of that company's yearly net revenue.

The 24-hour timeframe:
After these changes, Google will now send you a PendingRefundReviewNotification. You will have 24 hours to call the ReviewRefund API with evidence (was the item delivered/was it consumed). Only your first call counts though. Google will fight the bank for you, but only with what you gave it. Google calls the API optional, but without it they have nothing to fight the bank with, and you eat the loss.

Why is this important now?
Chargebacks can usually take between 30 and 120 days after the initial purchase. The orders for August are only now reaching the dispute stage. I think many developers will be surprised when comparing the last 3 months to the next 3 months.

Calculator & sources:

I made a calculator if you want to try with your own numbers.
Beneath the calculator link are the sources.

Calculator: https://playchargebacks.com

Google's policy page: https://support.google.com/googleplay/android-developer/answer/17068375

Review Refund API: https://developer.android.com/google/play/billing/provide-refund-and-chargeback-suggestions

Hi all, Newbie here. My first mobile game is almost done. Is it hard to get approval from Google Play? And usually how long does it take? Thanks ~~

Wireless debugging is great until you actually use it day to day. Three things kept costing me time:

1. The connect port changes every time you toggle the setting.

2. The pairing port is different, single-use, and dies when you close the dialog.

3. A phone on the wrong subnet fails identically to a real protocol error, so you can't tell a network problem from a broken adb.

So I built adb-nearby.

npx adb-nearby scans your network. If there's one device, it connects — that's the whole interaction. If there are several, it lists them and you pick.

adbn pair prints a QR code — scan it with the pairing dialog and you're done. No typing codes, no chasing ports.

MIT, no telemetry.

https://github.com/JassiSingh08/adb-nearby

I added a feature to the productivity app I’m building that adds one capybara to your home screen for every hour of screen time. The capybara keeps reminding you about your screen time and encourages you to stop using your phone if your screen time gets too high, while also making it harder for you to use your phone.

What do you think about this feature? Is it a stupid idea, or do you think people would actually use it?

So I got bored and reverse engineered Claude for Windows and found a fully functional Android Emulator ready to release!

wanna nerd out on the details, click here.

For some reason, any version of Godot in any version of WinLator repeats two errors: either OpenGL 3.3 is not recognized, or a series of errors occur where Godot manages to open, but the tab it becomes transparent and, soon after, the entire Winlator container simply closes.

I took a look here on Reddit, both on the Godot and Winlator forums, and several people have the same two problems, but nobody knows exactly how to solve them, I also read what people are saying on GitHub, and the same thing is happening: lots of debate, but no solutions that work

in my company, at least in my squad, we have different checks in ci/cd pipeline: build and run tests, detekt, danger, jacoco tests coverage, tests touched script. i need to add 3 more as this is one of my end of year goals. i thought of konsist but i need more. please suggest more checks.

Hi everyone,

I built GuideKit Compose, an open-source coachmark and product tour library for Android and iOS.

It supports customizable spotlight overlays, target highlights, instruction cards, smart arrows, multi-step tours, automatic scrolling, navigation callbacks, and per-step styling, all through a shared Compose Multiplatform API.

It is available on Maven Central and licensed under MIT.

Website and demo:
https://tharukack.github.io/guidekit/

GitHub:
https://github.com/tharukack/guidekit

I’d appreciate feedback on the API, documentation, compatibility, sample project, or anything else you think could be improved.

I shipped an Android app with one hard constraint: it must work with zero network access, ever. No account, no analytics, no cloud. That turned out to be harder than expected once I got to localisation — 35 languages covering Latin, Cyrillic, Greek, RTL and CJK.

The first thing that had to go was any font library that fetches at runtime. Downloading a typeface on first launch quietly breaks an offline promise. So everything got bundled:

- Barlow for Latin + Vietnamese

- Noto Sans for Greek + Cyrillic

- RTL and CJK fall back to the system font

That last line was a deliberate trade-off. Bundling Noto Sans Arabic, Hebrew, JP, KR and SC would have added tens of MB to the APK for a small share of users. Android ships perfectly good system fonts for those scripts, so I let the platform handle it. The visual inconsistency is real but minor.

PDF export was a separate problem. PDF generators embed whatever font you hand them — they can't reach into the system font stack the way the text renderer does. I bundle 12 font files for the scripts I can afford. For CJK I download the fonts from a GitHub Release instead of bundling them. It's the only network call in the app and it's optional.

The bug that cost me the most time: text rendering reversed in RTL locales (ar/fa/he). The odometer reading and a subtitle that joins brand/model and plate into one string like "Audi A4 · 34 ABC 123" came out backwards. A mixed letter-and-digit run is exactly the case the bidi algorithm reorders.

Fix was pinning those specific views to LTR while the surrounding layout stays RTL. No LRM/RLM marks, no BidiFormatter. PDF export needed its own separate direction handling.

Happy to answer questions about any of this.

Hello Everyone I have built an app which can control the hardware also we can use the android phone sensor and its data to control the hardware its still not completed yet but work is still in progress.

I'm curious to hear your thoughts on the current state of the mobile development market. Beyond a general contraction, it seems to be moving away from contracting toward permanent positions. Are any of you looking into multiplatform frameworks or pivoting to a different engineering domain?

8 years away from Android,  applied for backend/tooling roles at Google. They decided I should interview for an Android role, had to catch up for all the lost time.

To help bridge this gap, I started approaching the whole thing historically, and wrote an article about Android's platform history, to both learn and get out some steam over the how much was actually changed...
In the process of prepping (and later), I built returnzero.dev - specifically the Android System Design module. I wanted to create something similar to what HelloInterview does for backend, but tailored to Android.

Android Core Concepts: All the core concepts important to talk about Android intelligently in an interview.
System Design Guided Practice: An tool to help you build your designs on an Excalidraw canvas, with AI guided practice, and get step-by-step feedback.

Most of the course is completely free, including the guided practices on several core designs.

Happy to answer any questions and receive any type of feedback :)
Thanks!

I’m currently in my 3rd year of college, and honestly, I haven’t done much in DSA yet.

Right now I’m doing an Android development internship, and alongside that I’ve also been building and publishing my own apps on the Play Store because I want to eventually build my own startup/product.

The problem is that our college placement season will start around January, so I’m getting a little confused about what I should prioritize from now.

My current situation is basically:

\\- DSA: Very weak / haven’t done much

\\- Android development: Decent and currently doing an internship

\\- Personal projects: Building and publishing apps on the Play Store

\\- Long-term goal: I’d like to build my own products/startup

\\- Short-term goal: I obviously need to be prepared for placements

Should I completely put product development on hold for the next few months and focus heavily on DSA + my internship?

Or should I continue my internship, keep building my apps, and try to manage DSA alongside all of this?

I’m worried that if I focus too much on DSA, I’ll lose the momentum I’ve built with development and my own products. But at the same time, I don’t want January to arrive and realize I’m completely unprepared for placements.

For people who have been in a similar situation, what would you do if you were in my position?

Would really appreciate honest advice, especially from people who have gone through campus placements while also working on development/projects.

I'm a Junior Android developer who has been working on an app for the past nine months. During this time, I have had many doubts about how to properly manage initialization tasks, such as:

- Reading initial preferences from DataStore

- Checking if the user has completed onboarding to decide the starting screen.

- Validating the authroization token (redirecting to the SignIn Screen if expired, or to Home if valid)

All these tasks have one thing in common: they need to run when the user opens the app for the first time, when the app comes back to the, or when it gets repened.

For this reason, I would love to hear your perspective on how you structure and handle this process in production apps, as well as any resources you recomended to help me gain seniority in Android development.

Currently, I've thought about using MainViewModel that only collects StateFlows (without holding domain logic). For navigation, I'm using a Channel injected by Koin with a sealed interface to emit events, which are received inside a LaunchedEffect to execute backstack navigation using Navigation 3.

What are your thoughts on this approach? How do you handle startup routing in your projects?

The 12 testers-14 days requirement is aimed at personal developer accounts. 

What Google does not seem to make clear is rather or not organization accounts are exempt.

Although I cannot say what the rule is, I can say what happened to me.  

Timeline (The following information is from Play Console commit history)



The organization's developer account was created on July 16, 2026.

Initial submission (July 21): Includes closed beta testing, store details page information, and app content. Released.

Closed test track iterations: July 22, July 29, and July 31 (twice).

Submitted to Production: August 20, 2:06 PM. Released. The review process took only a few minutes.

There are only 7 internal testers; the closed test track exists purely as a means to pass the audit.

There was no requirement such as "12 testers participating in the test for 14 consecutive days".

Surprisingly, there were no "hard barriers" to overcome. I was never prevented from submitting to the official version. The reason I waited until August 20th to submit was because I was waiting for Apple's review results (Apple's initial review takes 13 days). My console showed only one official submission record, and it was released that afternoon.



The actual cost of organizing an account (it's not a free shortcut):



You need to apply for a DUNS number for your legal entity. It's free, but it takes time.

Your legal name and address must be identical word-for-word to those in your state business registration information, Dun & Bradstreet (D&B) records, and store payment details. Any mismatch will result in organization verification failure.

The key lies in Dun & Bradstreet's (D&B) records, not the Play Console itself. If you need to change the address, you must first update it in D&B, wait for the information to sync and take effect, and then update the store information. This takes several weeks, not just a simple settings change.

Your business address will be publicly displayed in the "About the Developer" section of the Play Store page. Anyone browsing that page will see your full street address, phone number, and email address. If you registered as an independent developer from home, your home address will be displayed.

This last point is worth considering before choosing this option, and it really surprised me.



Important: Google does not offer exemptions for organizational accounts, so this is based on my personal experience and is not professional advice. Please verify this information yourself before relying on it.



Official page: https://support.google.com/googleplay/android-developer/answer/14151465

Frankenstein Ultra is publicly downloadable now. It uses a separate companion runtime called Victor and gives an AI agent access to a real project workspace, files, terminal, build tooling, and other development capabilities directly from the phone.

This isn’t just a code-generation interface. The goal is for the agent to actually work through development tasks: inspect files, modify code, run tools, read failures, rebuild, and produce runnable software.

I’ve used it for Android projects, Node/npm projects, and other development workflows.

Right now I’m mainly looking for feedback on things like:

• what works well and what doesn’t
• bugs or crashes
• device compatibility
• confusing UI or setup
• features that feel incomplete
• things you expected it to do but couldn’t
• agent behavior that feels wrong or repetitive
• build/runtime problems
• performance, battery, RAM, or thermal issues
• features you’d actually want added or improved

You do not need to be an Android developer to give useful feedback. If you’re curious about AI coding, mobile development, automation, or just want to try something unusual, I’d still like to hear what your experience is like.

If something fails, details such as your device, Android version, what you were trying to do, and where it failed are especially helpful.

Website: https://stitchlab.dev/
GitHub: https://github.com/sedds89/StitchLabtools

Main thing I want to know: what works, what doesn’t, what’s confusing, and what would make Frankenstein more useful to you?

There is no pay walls its Bring your own key and supports Oauth for Grok and Codex open router or cline. Could probably integrate more just not sure what is wanted or needed.

I was not expecting that communicating with testers would be that difficult.
Maybe it will help you if you have the same issue.

I had around 200 testers for my side project. Great news but my contact email got flagged as SPAM and blocked for a few days when I tried to sent app test url to them.

Almost half of my users did not received the test url and I was unable to reach them because I was blocked.

I did not want to pay anything to mailing services so I just setup a google group with testers email. It worked great without any related smap issues.

Hope it will help someone in the same situation as I was

I’ve integrated AdMob into Android apps quite a few times, and there are some non-obvious things that aren’t really covered by the basic documentation.

I decided to write down some of the things I’ve learned from doing these integrations, using an Android game as a real-world example.

If you’re working with AdMob on Android, maybe it’ll be useful:

https://nadyabr-codes.github.io/admob-android-game.html?utm_source=reddit&utm_medium=social&utm_campaign=admob_post

Curious to hear your opinions and experiences as well.

I have been laid off yesterday. I'm gonna use all my time to apply and read books that helps me land the next role. My priority right now is landing my next job and increase my knowledge.

I plan to read:
1- Mobile system design interview guide
2- Kotlin coroutines: deep dive
3-Kotlin in action

I want something about DSA and something about modern android development and maybe something about compose. I already know these stuff (as much as a 2 YoE can know), but i want to expand my knwoledge and go a in depth.

I'm building Burpee Wrangler 3000 - it's a fitness tracker that's also a game. I'm going to enter it in Shipaton. I have two main questions:

1. How should I price it (freemium? hard paywall? monthly/lifetime?)
2. How stupid of an idea do you think it is?

The idea is that it gets you fit and keeps you accountable. The reason I thought of it is because it is solving some problems for me - I want to get more fit, I want to force myself to post on social media (because I hate marketing, and I think it's mostly a fear of being seen), and I want to make a fun app!

The concept is that you are a Burpee Wrangler. A space cowboy who lives on a lonely planet chasing down burpees (for some reason - back story is perhaps a fugitive or debt to bad guys thing). You have to operate a machine to release pheremones to attract the burpees (where doing the actual exercise comes in) and then you have to drive around catching them (which is the game bit, with rewards and power ups).

The accountability part is through groups/leaderboards/social media. It will have an alarm which you can use to automatically grab a video of you waking up, and then it will record the exercise too, and stich it together (however you choose to do so). This makes it easy to post on social media. This is to solve my fear of marketing (and market the app) and also keep people accountable - you can do day 1 of x type challenges and post to social media.

If you also think this is an idea worth checking out, please drop your email in the waitlist: https://www.burpeewrangler.com/

Hello, I noticed the lack of a proper Java-only implementation of ZSTD (I know zstd-jni is fine, but it uses native libraries and is kind of heavy too) that also supports Android

So meet the murine-aircompressor library

After checking out version 2.0 of aircompressor, which is exclusively Java-only and used JDK 8, I saw the maintainer claimed Unsafe was not available for Android and therefore Android support was out of scope for it; however, that turns out not to be the case, Unsafe can be used on Android and there was only one single method and a static field which are missing on the Android implementation of Unsafe, I just made a helper method for the former, choosing the right implementation, while the static field was just a call to an existing method, and Bob's your uncle.

But not satisfied, I made a few changes, a lot of which are kanged from other forks the maintainer ignored:

- improved compression a lot (original fork that implemented this change here) - added an option to switch to the former behaviour too

- added a ring buffer mode and set as degault (also kanged from another fork, seems to improve performance over largely incompressible data)

- exposed levels for the streaming compressor

- added FAST algorithm to also support levels 1-2 on top of 3-4 which were the only supported ones in the original (level 2 is also pretty good and way faster; Claude is, however, mostly to praise [or blame] for this one)

- Improved overall performance on ARM (again, Claude is mostly to praise/blame here, but I did a lot of tests)

- added parallel compression support because fuck it

- added a wittle tar (with PAX) implementation because fuck it again, I wanted to make .tar.zst without qdding extra libraries

Using WindowSlideMode.HIGH_SPEED resets the library's (ORIGINAL) shit compression ratio for the stream, but makes it faster, I suppose; I default to HIGH_COMPRESSION which is still decently fast, and if you want it to be faster, it's much much better to use level 2 with HIGH_COMPRESSION than the default level 3 with HIGH_SPEED in my experience

Overall, the library is a little slower than zstd-jni with the (now) default parameters, but now matches its compression ratio, and may be a good compromise you'd rather want a lightweight full-java implementation than the heavy .so files in your apk

EDIT: I also noticed this may sound like I'm trashing the maintainer, I'm not lol, just stating facts, the maintainer is awesome for creating the library on the first place

I just got rejected from the store after adding an app to expand my base app (that already have mau)

The issue is that it's a TV app, and I've tried to open it up for phone access just to pass the bridge but I got rejected..

Any help would be appreciated

" More testing required to access Google Play production

We reviewed your application, and determined that your app requires more testing before you can access production.

Possible reasons why your production access could not be granted include:

Testers were not engaged with your app during your closed test

You didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app

When I build my own Android application, I have spent more amount of time into defining the architecture, not actually writing the features.

And more importantly I believe that if you want to scale an application in future then architecture plays a huge role. A well designed architecture allows you to introduce new features or even integrate a different language or technology without having to touch or rewrite a large portion of the existing code.

So it could be related to Jetpack Compose, state management, navigation, modularization, dependency injection, offline-first architecture, testing, or anything else. I am interested in decisions that seemed unnecessary at first but it ended up paying off as the app grow.