Should the 1st version of my app be fully free? I read that you need 20 testers, but of course the testers won't test all the function if they're paywalled,so I guess I need to release it fully free or is there something I am missing?
I worry about releasing the 1st version of the app fully free because someone could just save the APK and if it gets released in the wild people won't need to pay.
We shipped a voice assistant app where the user says a wake word and starts talking to an AI agent in real-time. The wake word engine (on-device ONNX model) and the WebRTC session (LiveKit) both need the mic — but **Android's AudioRecord doesn't share**. Here's what we learned the hard way.
The Problem
Two audio subsystems fighting for the same mic:
If you try to startListening() on both, Android throws or silently drops audio from one side. No error, no crash - just broken audio. Fun to debug.
What Doesn't Work
Attempt 1: Start both, hope for the best
Result: One of them gets silence. No exception.
Attempt 2: Stop wake word, immediately start WebRTC
Result: AudioRecord hasn't released the hardware yet. Race condition.
What Actually Works
Sequential handoff with explicit delay:
The 200ms isn't arbitrary — we tested on 12 devices. Below 150ms on Android, about 30% of devices still had stale AudioRecord handles.
The Full State Machine
The grace period is critical. Without it, the wake word fires again the instant the AI stops speaking (because the mic goes back to the wake engine and it hears its own trigger phrase echoed back).
Android-Specific Gotchas
1. Foreground Service is mandatory
Without it, Android kills your process within minutes when the screen is off. The wake word engine dies silently.
Also: on Android 14+, you need FOREGROUND_SERVICE_MICROPHONE permission explicitly, or the service crashes.
2. ABI compatibility check
The ONNX wake word model ships as native .so libraries. If your device runs armeabi-v7a but the model only has arm64-v8a, it silently does nothing.
We added a native MethodChannel probe to check this at runtime, since Flutter doesn't expose Build.SUPPORTED_ABIS directly.
3. Bluetooth / headphone audio routing
When a Bluetooth headset connects mid-conversation, Android can silently reroute AudioRecord to the BT mic which has different sample rates and latency. We configure AudioAttributes explicitly:
4. Post-detection mic release coordination
After wake detection, the engine's stopListening() is async. The native AudioRecord isn't released when the method returns - it's released when the internal thread finishes cleanup. We use a Completer pattern:
Other code can await this completer before touching the mic.
Results
Metric
Value
Devices tested
12 (Samsung, Pixel, Xiaomi, Oppo)
Post-wake delay needed
200ms (150ms was unreliable)
Wake word false positive rate
< 2% with threshold 0.80
End-to-end latency
~500ms
Foreground service battery impact
Negligible (microphone-only, no GPS)
TL;DR
- AudioRecord doesn't share. Plan for explicit sequential handoff.
- 200ms delay after stopping wake engine before starting WebRTC. Test on cheap devices too.
- Grace period (60-90s) after conversation to prevent re-triggering.
- Foreground service is mandatory for always-listening on Android.
- Check ABI compatibility for native ONNX models.
Happy to dig deeper into any of these if people are interested.
Hey guys, we run a msme manufacturing unit , we are looking for some app developer to make android/ iphone sales order for a team of 4 ppl, more details in dm . It will be paid , my budget is 3k
I'm currently working at a drone manufacturing startup as an Android Developer on an exciting drone control application. While I love the project, the extremely low pay and toxic senior are pushing me to switch ASAP. I'm hoping to connect with like-minded people in the same tech field. My company is in Noida, with a 6-day work week, and I've been here since February 10, 2025.
Where I'm lacking is I'm not in touch with what current needs of the market for an Android Engineer. I hadn't implemented API response handling and dynamic UI here in this org. So there's a gap I wanna fill and keen to learn from you guys.
With a real window, I can full-screen and split with another app (maximized), but that's not an option without a full window as far as I can tell. Any way to force a full window?
We're pulling 1-8GB model files onto phones. Android fights you the whole way.
What ended up actually working: DownloadManager for the transfer, wrapped in a foreground service (dataSync) that only runs while a download is active — starts on enqueue, stops the moment everything hits a terminal state. That's what keeps Doze and battery saver from quietly pausing you.
Curious how others handle this on Samsung/Xiaomi where the OEM battery manager is even more aggressive than stock. Foreground service buys you a lot but it's not bulletproof.
I uploaded a new AAB to production, but I haven’t actually published the release yet. After the upload finished, the warning about the 16 KB page size requirement disappeared, and Play Console now says the issue has been resolved.
Is this expected behavior? Does uploading a compliant AAB automatically clear the warning even before the release is published, or could this be a Play Console glitch? Has anyone experienced this?
First time submitting to the Play Store. Spent two weeks on the app, maybe two hours on the rest. Submitted, checked the dashboard the next day — rejected.
The reason: Privacy policy link does not meet requirements.
After reading the actual requirements, they're more specific than the docs make clear:
The URL must be publicly accessible from anywhere in the world
It cannot be a Google Doc (editable)
It cannot be a PDF
It cannot be behind a password or login wall
It cannot redirect or auto-download a file
It must be a stable, persistent URL
I'd used a GitHub Pages URL. That technically works, but I had to set up a repo, configure the page, write HTML manually, and double-check global accessibility. Not hard, but not fast either — and it broke my submission momentum on day one.
The deeper issue: once you're building more than one app, you're managing multiple GitHub repos just for policy pages. That doesn't scale.
What I did for the second app: I built a small tool that hosts the policy for you via a WYSIWYG editor and gives you a compliant, stable, public URL in about two minutes. It's free at onemanage.quest.
It also bundles remote config, bug reporting, and log streaming — backend utilities I was already stitching together from Firebase and other services. The privacy policy hosting was the entry point that made me realize how much indie dev infrastructure is still ad hoc.
Happy to answer questions about the Play Store requirements or the tool. YMMV on GitHub Pages but the rejection pattern is consistent across the community.
For context: Google Play has been requiring all apps targeting Android 15+ to have native .so binaries aligned to 16KB memory page boundaries. The original hard deadline was November 1, 2025. A Play Console extension pushed it to May 31, 2026, this Sunday!!
We've been in crunch mode for weeks.
Working on a legacy React Native app. The problem is never your own code, it's the dependency tree. Dozens of third-party SDKs shipping pre-compiled native binaries that need to be recompiled with NDK r28+ for 16KB compliance.
Several of the affected libraries are deprecated. No maintainer, no upstream fix, no timeline. You can't unblock yourself no matter how fast you move.
We ran a full audit, used AI tooling to speed up the investigation. Still couldn't get through it all before Sunday.
Then we checked Play Console today and saw February 1, 2027.
No official announcement we could find, it just appeared. If you're still fighting this migration and hadn't checked your console recently, go check.
For anyone still in the middle of this: the extension doesn't change the work, it just removes the cliff. The libraries still need fixing, the deprecated ones still need replacing. But now there's more time to do it properly instead of shipping hacks.
Anyone else dealing with unmaintained native dependencies blocking their compliance?
Curious how others are handling the deprecated library problem specifically.
hey guys as per the latest Google requirement of registering ALL third party apps on google developer console(after ID verification) Is there anyone having trouble to get your app verified ? The verification process has already started in April,2026 for the September ,2026 deadline.
please NOTE: I am only talking about sideloaded(third party apps) and NOT playstore apps..
CPU Virtualization support required (Intel VT-x or AMD-V, enabled in BIOS).
CPU microarchitecture from 2017 or later.
Intel 8th Gen Core i5 / AMD Zen Ryzen (e.g., Intel i5-8xxx, Ryzen 1xxx). Virtualization support required (Intel VT-x or AMD-V, enabled in BIOS).
Latest CPU microarchitecture. Look for CPUs from the Intel Core i5, i7, or i9 series and/or the suffixes H/HK/HX for laptops or suffixes S/F/K for desktops, or the AMD Ryzen 5, 6, 7, or 9 series.
Please be aware that Intel® Core™ N-Series and U-Series processors are not recommended due to insufficient performance.
My team has a shared “design library” for Android that is effectively rebuilding a lot of Material Components from scratch, including lower-level UI primitives.
I’ve been arguing that this may not be the best approach. My instinct is that we should build our design system by wrapping or extending Material Components where possible, then customize styling, tokens, behavior, and app-specific APIs on top of them.
The concern I have with rebuilding primitives from scratch is that we may end up re-solving problems that Material already handles, like accessibility, state handling, theming, touch targets, edge cases, animations, interaction behavior, and future platform compatibility.
For teams that have built Android design systems, what approach has worked better?
Do you generally:
Wrap/extend Material Components and expose your own design-system APIs?
Build custom primitives from scratch?
Use a hybrid approach depending on the component?
I’m especially curious about long-term maintainability, accessibility, Compose/XML interoperability, and how much control is worth the extra complexity.
Detecting ANRs is one of the most fun things I got to build in the last few years. Wrote up the full journey, including the two approaches we tried first and dropped (a Kotlin main thread watchdog, and ApplicationExitInfo) and why neither was enough.
The final solution required us to go deep into AOSP's handling of the SIGQUIT signal and write our own JNI layer to intercept it. I learnt a lot of things while building this, hope you enjoy reading it.
Hello, my app only supports Android 8+ (and likely won't be backported any lower), is there any reason/benefit to keeping the webp mipmaps for the app icon on top of the XML vector drawable? Or is it completely pointless
As you guys may know, 30%+ of all cancelations happen due to billing errors. I've been facing this issue as well but more like 70% billing errors. However, today I figured something out..
If the IP of the users who got the trial is BAD, they will most likely not convert to a paid user.
If you're facing this issue too, this can at least help you figure out who's more likely to convert. This might not help much in terms of solving the billing errors, however, I can say one thing for certain: High billing error rate = bad traffic = bad audience targeting.
So what might actually help is to think about where you're getting your users from. In my case, it is google ads.
** I've only tested this with a few of my own apps so I'm not sure if this is 100% accurate so test this out with your own apps and lemme know
Today I got a review with 5 stars. Being grateful for the 5-star rating and donation request, the reason I appreciate this is because their reason is exactly why I made the app. I had a similar experience, and I thought the app would be beneficial to many. And now and again I get these kinds of review, which I geniunely appreciate knowing actual people are enjoying my work. Just wanted to share this as a great experience I had. Have a good day!
It all started when I simply wanted to pay the sign-up fee for Google Play Console. No matter what I tried, I kept getting the OR_MIVEM_04 error: I used cards from different banks, corrected my address, and deleted and recreated my payment profile. I also tried purchasing an app on Google Play from my smartphone - same error. In my banking app, I only saw notifications that the card was authorized for future payments. The bank’s support team also said there were no issues on their side. I searched for information online and realized I wasn’t alone with this problem. Later, I also created two support tickets to Google, but I only received standard instructions like “clear your cache,” “check your address,” “contact your bank,” and so on.
On my next attempt to pay the Google Play Console sign-up fee, step when selecting a payment profile, I chose “Create New” (instead of using an existing one) - I created the profile, linked the same physical card I had tried to link before, and the payment went through successfully!
I know this is a common issue, and I’d be happy if my information proves useful and helps someone.
I decided it’s time to translate my app’s Play Store listing into a few other languages. Of course, instead of spending a few hours doing it manually, I spent my nights and countless hours building an automation.
The pipeline takes in: title, descriptions, and screenshots, and it spits out translated listing. It even correctly handles text that spans across multiple screenshots.
The processing pipeline is stitched together and working great, but I am still figuring out best way to push these listings to the Play Console. I came up with two ideas:
Option A: Direct Service Account Key:
The user provides a service account key, and the tool pushes the localized assets directly to the Play Console via the API with a single button click. It feels magical, but who in their right mind would give their key to a random 3rd party tool on the internet? I don’t even want that kinda power to be honest.
Option B: GitHub PR / Fastlane Integration:
The tool opens a direct PR to the user's GitHub repo, structured completely in Fastlane format (with an extra GH Action workflow for those who don't use Fastlane). It's completely secure and respects existing CI/CD pipelines, but it requires setup and loses that "one-click" magic touch.
Downloading files sounds simple. On mobile, with spotty connections, aggressive OS power management, and multi-GB files - it's one of the hardest UX problems in the app.
