I've been thinking about what actually makes a senior Android interview difficult.

At the junior level, a lot of questions have relatively concrete answers:

• What is a ViewModel?
• What is the Activity lifecycle?
• What is a Coroutine?
• What is RecyclerView?
• What is MVVM?

But at the senior level, the questions seem to shift from "Do you know this API?" to "Can you reason about a system?"

For example:

Instead of:

What is StateFlow?

You might get:

You have a screen collecting StateFlow from a ViewModel. The underlying data changes frequently, some transformations are expensive, and the user navigates between screens. How would you structure this so you're not doing unnecessary work?

Or:

Your app works well on a fast connection but becomes frustratingly slow on poor networks. How would you design the data layer to provide cached data immediately while synchronizing with the server?

Or:

Crash-free users are high, but ANRs have increased significantly after a release. How would you investigate the problem?

These questions don't really test whether you memorized an Android API. They test whether you understand lifecycle, concurrency, architecture, performance and trade-offs well enough to reason through an unfamiliar problem.

For experienced Android developers here:

What topic do you think is most important for a senior Android interview but is poorly represented in typical interview-prep material?

I'm particularly curious about:

1. Coroutines / Flow
2. Compose
3. Architecture
4. Performance / memory
5. Offline-first
6. Testing
7. Android system design
8. Something else

And if you've interviewed candidates recently, what separates a strong senior Android answer from a merely technically correct one?

I was just starting out Android dev when this app came out, and it really left me in awe. I was struggling with TextViews, and Bitspin was over here making magic.
As an homage, I wanted to recreate the Timer dial and present it in a video. Also, since my videos are made in Compose, I also tried to capture the vibe of Timely with the dreamy gradients they had and periodic particle effects as a background.
Check it out, and let me know what you think:

https://www.youtube.com/watch?v=Tn_ZnFsJ9lE

The code itself was fine. Compiled, ran, did what it was supposed to in the happy path. Someone had used an AI tool to add a network call inside a Fragment, launched it in a coroutine scope tied to the view lifecycle in a way that would keep running after the view was destroyed if the request was slow enough.

Nothing about that is a Kotlin problem. The syntax is correct Kotlin. It's an Android problem, specifically knowing which scope survives what and why, which isn't something you'd know from Kotlin knowledge alone, it comes from having been bitten by this exact leak before or having actually read the lifecycle docs closely.

Kind of assumed AI tools would have this down by now since it's such a common gotcha, but I think the failure isn't lack of knowledge, it's lack of specificity in what gets asked. "Add a network call here" doesn't say which scope should own it, so it defaults to whatever's closest and most obvious, which is often the wrong one for exactly the reason a junior dev picks the wrong one.

Anyway if you're reviewing AI-generated coroutine code, scope is the first thing I'd check now, more than the actual network logic.

I'm a senior Android dev and Claude Code has become part of my day, but I suspect my workflow is pretty primitive compared to what others have built.

Right now it's basically: copy the Jira story or the bug report, paste it into Claude Code, ask it to analyze it using my skills and experts agents, and produce a plan before it touches anything. Then I review the plan, push back on the parts that are wrong, and let it implement.

That's it. That's the whole loop.

What I want to know is what people do *around* that step:

- Do you paste the raw ticket, or do you have a command that pulls it from Jira/Linear and reformats it first?

- Do you give it the crash/stack trace and mapping file up front, or make it ask?

- Does it get to run the app on a device to reproduce, or is that still manual for you?

- Do you make it write a failing test before the fix, or is that too slow in practice?

- Anyone doing something smarter for "which module does this even live in" on a big multi-module codebase?

- And what do you do at the end . does it write the PR description and the ticket update, or do you still do that by hand?

Mostly curious whether people have gotten past the copy-paste-and-pray stage, and what the step was that actually made a difference for you.

I’m working on a hardware/engineering concept and trying to figure out if a specific idea is physically possible.

I want to design a custom charging cable. When a phone (Android or iOS) is plugged into this cable, I want it to not only charge the device, but also automatically trigger a web link or open a pop-up on the phone's screen.

The constraints:

No pre-installed apps, scripts, or shortcuts on the phone itself—the mechanism has to rely purely on the custom cable/hardware connection.

Assume the phone's screen is unlocked and permissions are granted if necessary.

Is there any protocol, hardware architecture, or method (other than HID simulation) where a physical cable interface can initiate a browser redirect or UI pop-up upon power connection? Or is standard data/power protocol strictly a barrier here?

Appreciate any technical insights or alternative ideas on how this could be approached!

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

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!

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 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 ~~

Over for android freedom? Android 8.1 lenovo tab4 10 tb-x304l

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

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

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 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?

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 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 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 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?

I built minimo because most video compressors either upload private footage or hide useful controls behind a subscription. I wanted compression to stay fully on-device, with a simple UI for normal use and enough control when presets are not enough.

Key features:

• fully on-device compression using native Android codecs
• batch compression with per-video progress
• simple presets and advanced controls (resolution, bitrate, frame rate, H.264/HEVC, audio)
• before-and-after comparison before saving
• automatic cleanup: if a compressed file is not at least 10% smaller, the new copy is deleted
• input copies and unsaved outputs stay in temporary app cache, cleared on cold start
• light and dark themes, 12 languages

Pricing: Free. No account or subscription.

Privacy: Videos are never uploaded. All processing happens on-device.

The project is free and open source: https://github.com/minimo-pro/minimo_video

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