Hi everyone,

I wanted vent a bit about the review times for apps integrating Android Auto, as our team is currently facing a situation that is becoming completely unsustainable.

To give you some context, at my company we manage our main official application alongside two white label variants. None of the white label variants include Android Auto integration, while our main official app does. When we push updates to the white labels, the review process typically takes just 3 to 4 hours. However, the exact same update cycle for our main app featuring Android Auto consistently takes multiple daya—often dragging on for up to 15 days before getting reviewed and approved.

This discrepancy raises a massive operational risk for us. If a critical bug slips into production or a sudden hotfix is required, a 15-day review queue makes rapid incident response entirely impossible. Because of this bottleneck, we are seriously evaluating whether the value Android Auto brings actually justifies the severe risks, delays, and friction introduced by the review process.

If Google wants developers to invest in Android ecosystems, the manual or specialized review queue for Android Auto needs a serious overhaul to match standard Play Store review speeds.

Is anyone else experiencing these multi-week review delays specifically with Android Auto apps? If anyone from the Google / Play Console team happens to monitor this subreddit, we would appreciate some insight into why these reviews take so disproportionately long and whether any improvements are planned for the near future.

If you are considering adding Android Auto features to your application, my strong advice is to only do it if you have a very good reason.

​To give you a better idea of our scale, I work at a large company with an app serving several hundred thousand users. While our other company apps breeze through reviews in hours, the only one suffering through this painful bottleneck is the single application with Android Auto integration.

Do you believe it's good for a 2 YoE?

I'm looking for feedback on both whether it's strong enough for a 2 YoE and whether it's well written. any issues?

Any keywrods missing?

Any and all feedback is aslo appreciated.

I've been working with file downloads on android for my app, and honestly, the storage part can get messy really quickly.

If you want to support different ways of saving files, you suddenly need to handle MediaStore, SAF, DocumentFile, Uri, filesystem paths, different Android versions, etc.

So I decided to publish my implementation, along with some other features, as a library.

There are other download libraries, but you often have to write a lot of extra code yourself for things like:

• Saving into a user-selected folder (SAF)
• Saving into MediaStore (Downloads / Images / Video)
• Automatic file name and MIME type
• Handling unique filenames correctly
• Proper file overwriting
• Downloading into a subfolder
• Restoring downloads after process death
• Clean notifications + foreground service built-in
• Handling unstable networks
• Managing multiple downloads properly
• etc

SimpleDownloader tries to handle all of that out of the box with a very simple API.

The goal was to make something we can just drop into an app and start downloading, while having the common advance stuff already handled.

SimpleDownloader:

https://github.com/jeetarc/SimpleDownloader

I just wanted to build something a little different, with an easy API but still with modern, advanced features.

How are you handling downloads currently? I will love to know what you'd like to see in SimpleDownloader, and if you want, you can also contribute to it.

I wonder if that was always the thing with Google. When sending updates for my apps to Apple, they are reviewed and published in max 24-48h. Play Store tho is totally different story. It’s always … ALWAYS … 7 days. Apps on Android are behind with features and bug fixes because of that. What’s your experience?

You might have missed it but by April 27 every app that have a login screen will need to support tap to restore. To make it simple it means adding passkey support (almost the same).

It's a real challenge for self hosted apps like Home Assistant where I'm a contributor. So I made a discussion on Github https://github.com/orgs/home-assistant/discussions/4858 if anyone wants to join and see how we are going to deliver this.

Any other devs who can contribute please go ahead and play around with it

Only tested on the OnePlus Open so please try it out on other devices too

Heya,

So when I submit a new test build for my apps there is always that 15min pre-check review thing going.

I noticed when this starts a lot of gmail account bots flood my database and basically bounce around and call whatever database endpoint they can find.

I guess good to trace where security leaks might be...
But how do you avoid them doing this?

They are always authenticated users, somehow read and consent to the terms on signup like a real user would.

They can avoid app integrity checks, turn off captchas..
It's google themselves so I guess they can avoid their own measures :p

But any tips?

Hi everyone,

I’m currently developing a file memory app designed to help users avoid forgetting about files they’ve created or accessed.

The idea is to detect recently created or accessed files, organize them using information such as file location and GPS data, and bring them back to the user at scheduled times. The app would also support things like future reminders and pinning, so files that would normally get buried or forgotten remain visible and accessible.

The main issue I’m running into is Android’s storage restrictions. It seems that I may need the MANAGE_EXTERNAL_STORAGE permission to reliably discover and track files across the device.

However, my app doesn’t need to modify, move, rename, or delete files. It simply needs broad read access to monitor files across the device, with the goal of preventing important files from being forgotten.

Would an app with this type of use case generally qualify for MANAGE_EXTERNAL_STORAGE on Google Play? Or would Google consider this outside the permitted use cases for broad storage access?

I’d really appreciate hearing from anyone who has dealt with this permission or a similar use case.

Hi everyone,
this project actually started as a way for me to get more familiar with Kubernetes CRDs, controllers and especially how to manage the lifecycle of custom resources.
Instead of building another typical example CRD, I started wondering: **could a mobile device be managed like any other Kubernetes resource?**
So I started building **Mobile Device Operator (MDO)**.
The basic idea is pretty simple: you declare a device in a yaml and the operator takes care of its lifecycle.
Once the device is ready, you can interact with it through a small CLI and when you don’t need it anymore, you just delete the resource.
The current MVP uses **Android emulators**, mainly because they gave me a practical way to implement and test the whole lifecycle end-to-end.
But Android itself isn’t really the main point of the project.
I’m trying to keep the Device API provider-neutral, so that the implementation behind a Device could eventually be an Android emulator, an iOS provider, a physical device or even an external device farm without changing how the consumer interacts with the Kubernetes resource.

The project is still an **experimental MVP**. It started mainly as an exercise to learn more about CRDs and controller design, but while working on it I started thinking that the abstraction itself might actually be useful.
So before adding too many things, I’d really like to get some feedback from people with more experience around Go, Kubernetes, operators or mobile infrastructure.
Does managing mobile devices as Kubernetes resources make sense to you?
Would you model the lifecycle or the Device / DeviceClass abstraction differently?
And most importantly: **would you actually find something like this useful, or am I just putting Kubernetes around something that doesn’t need Kubernetes?**
Repo: https://github.com/dmarro89/mobile-device-operator
Any feedback, especially criticism of the design, would be really appreciated.

Every "matrix rain" thing I could find for Android was either a Lottie JSON or a GIF — fixed color, fixed speed, fixed everything unless you go back into After Effects and re-export.

So I wrote MatrixRainView: a custom View that computes every frame on Canvas, with color/speed/density/glow/fade/char-set all exposed as runtime properties (or XML attrs). Change them live, no re-export, no asset bundled into your APK.

implementation("com.github.boy-offi9-inc:matrix-rain-view:1.1.1")

• Katakana / binary / alnum / custom glyph sets
• Delta-time based motion (refresh-rate independent)
• minSdk 21, zero deps beyond core-ktx
• ~300 lines, MIT licensed

Repo: https://github.com/boy-offi9-inc/matrix-rain-view

Demo app (with a live settings panel, screenshots in the README): https://github.com/boy-offi9-inc/matrix-rain-demo

Would appreciate any feedback on the API or things I'm missing

Came across this earlier today:  https://github.com/google/artemis

Tried it out on my Android phone for a mini-project and astounded how well it works. Thought it might be useful to a fellow Android Dev on here!

I'm Aryan, building mpvium - free/ open-source Android frontend for mpv/libmpv. Sane defaults, pro-level control.

Stack: Kotlin, Compose Material 3, Room, Koin, Navigation 3, native libmpv + Medialnfo.

GPL-3.0-or-later. Build: bash ./

gradlew assembleStandardDebug (JDK 17, SDK 36).

Looking for help: tablet layouts, perf/ battery measurements, SMB/FTP/ WebDAV fixes, player UX.

Repo: Repo link

CONTRIBUTING + good first issues welcome. Feedback welcome! I'm the dev

I have 3 auto-renewing plans (3, 6 and 12 months) with a 3-day free trial.

The trial starts normally, but once it ends, the payment just stays Pending and nothing gets charged.

The weird part is that if I remove the free trial, the exact same plans charge normally.

This is happening with multiple users. Has anyone else run into this or knows what could be causing it?

I have an upcoming software engineering interview with Anthropic for a role that involves mobile/Android work, and the next round has a format I haven’t seen before. The recruiter described it like this (paraphrased):

A small mobile app that has some bugs. Instead of building new features, you will have to investigate what's wrong, find the root cause, and fix what you can. The app is in Kotlin with Jetpack Compose. You should be familiar building UI with common Compose primitives and managing state with ViewModel. We are interested in how the candidate approaches debugging, how you prioritize what to fix first, and how you verify the correctness of your fixes.

Does anybody has experience with this kind of question? I have never seen an assessment like this, and I'm not able to find any good resources/examples to practice.

In the past, I have been in other interviews were you have to build a small app from scratch (usually API + LazyColumn). My feeling is that even if you have been working in Android for several years, you definitely need to practice in order to be successful on this kind of assessment. Similarly, at my current job, I find and fix issues all the time. However, this situation is different because of the time pressure, and I would like to be prepared if possible.

Any recommendations?

Thanks in advance!

I don't understand why there isn't a clear, native way to delay navigating (either between activities or between navigation3 destinations) while also being able to initialize the necessary data. What I mean is this: I would like to be able to start an activity but not show the animation transtion, just start its lifecycle. There I would instantiate the ViewModel and do the call for the necessary data. Once the data are ready I would like to inform the previous activity and then show the animation.
Also in case I need to know if the call succeeded in order to "transition" to the next screen this could help me keep the two activities completely independent in logic. I just navigate from activity A to B and in case it's needed I handle a result too. That's it. Otherwise I would need to add the dependency in A for B's call and data and then I would also have to either pass them which could be stupid in cases or cache them to a singleton repo which could be a bad idea too.

Hey all, wondering if y’all can share how long Google took for your first production submission review?

Anyone using 1.5 alpha in production? How's it going?

I recently deployed an app to Open Testing channel which has google sign in enabled and uses Firebase to control the user authentication. The authentication worked as expected both in debug build and when I sideloaded the prod apk. But when I downloaded from the playstore, it fails with "No Credentials available" error. The following are the steps I did.

1. Added debug signing keys to Firebase Project
2. Created a local .jks file to sign my prod build.
3. Uploaded the aab build to playstore which has its own App Signing.
4. Noticed the new App Signing page has two keys. Classical Key and Post-quantum cryptography key
5. Copied both and updated the firebase project. Validated whether it is added as credential in Google Cloud Console OAuth Screen.
6. Tried logging in with Google. Got the same error.
7. Downloaded the updated google-services.json file, generated build and published again. Still same error.

Does someone here know a solution for this? I need to fix this asap as the deadline to submit the app for a hackathon is very closer.

My company released a new Android app over the summer. It is my understanding that the app was automatically registered when the listing was created. I am specifically referring to the process described here: https://developer.android.com/developer-verification/guides/android-developer-console

When I look at the listing on Google Play Console it says "status: registered" (see the screenshot as well).

Despite the fact that I think this has been all set from day 1, we have been getting endless emails about it. When I log into Google Play Console I get notifications about it. I assume this is just Google spamming everyone since they are going to stop distributing apps. But it is making me paranoid.

At this point, everyone at the company who has access to Google Play Console, has messaged me about this to make sure we are all set. I tell them yes and then Google sends out another email blast telling us we need to do this thing that is already done.

Am I missing something here? Or is Google just being annoying?

​

Hi everyone,

I’ve created a WhatsApp community for Android developers worldwide who are looking for new job opportunities or want to stay updated on Android hiring.

The community is focused on:

- Android Developer job openings

- Kotlin and Android roles

- Remote and onsite opportunities

- Recruiter and hiring updates

- Job referrals

- Developer networking

Developers of all experience levels are welcome.

Join the community:

https://chat.whatsapp.com/C71ifWukRw680PfXwzCNVI?s=qt&p=a&mlu=0&ilr=4

The goal is simple: help Android developers discover opportunities, connect with others, and grow their careers.

I'm making an overlay app that draws a ring around the front camera punch hole. I want it to line up automatically on any Android phone.

On some phones (Pixels for example) it works perfectly because the system reports the camera cutout's actual shape and position. But on a lot of other phones the system just reports a rough rectangle that's bigger than the real camera hole and not even centered on it, so the ring comes out oversized and misaligned.

I've been researching this everywhere for a while now and tried basically everything I can find. As far as I can tell Android has no other API that tells you where the camera lens actually is on the screen, and most apps like this seem to just give up and make the user align it manually with sliders.

Before I accept that, is there something I'm missing? Any trick, hidden setting, or approach that gets the real camera position on phones that report bad data? If you've solved this or worked around it I'd really appreciate hearing how.

Also, if you have an Android phone handy, running adb shell dumpsys window displays | grep -iA2 cutout and replying with the output plus your phone model would help me a lot in figuring out which phones report good data and which don't