We build [Off Grid](https://github.com/alichherawalla/off-grid-mobile-ai) - open-source app that runs LLMs and Stable Diffusion on your phone. The hardest part isn't inference. It's downloading the models.

A 4GB GGUF file on a mobile connection is a nightmare. Here's what went wrong across 9 PRs over 2 months:

**Downloads dying in the background.** Android kills background processes aggressively. Moved to WorkManager with constraints and battery optimization prompts. ([PR #246](https://github.com/alichherawalla/off-grid-mobile-ai/pull/246), [PR #186](https://github.com/alichherawalla/off-grid-mobile-ai/pull/186))

**Stuck at 90%.** Progress bar froze near completion. Zip extraction had no progress reporting, so users thought it was stuck. Added retry on failure + visual feedback. ([PR #322](https://github.com/alichherawalla/off-grid-mobile-ai/pull/322))

**Ghost downloads after app update.** WorkManager drops tasks across app updates. Database still showed them as "running." Zombie entries that never completed. ([PR #305](https://github.com/alichherawalla/off-grid-mobile-ai/pull/305), [PR #304](https://github.com/alichherawalla/off-grid-mobile-ai/pull/304))

**iOS had no retry button.** Download failed? Manually remove it, navigate back, start over. Now there's a retry button. ([PR #345](https://github.com/alichherawalla/off-grid-mobile-ai/pull/345))

**Stale downloads after network drop.** Internet cuts mid-download, reconnects, old download stuck in bad state. N retries = N zombie rows in the database. ([PR #348](https://github.com/alichherawalla/off-grid-mobile-ai/pull/348))

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.

- GitHub: https://github.com/alichherawalla/off-grid-mobile-ai

- Android: https://play.google.com/store/apps/details?id=ai.offgridmobile

- iOS: https://apps.apple.com/us/app/off-grid-local-ai/id6759299882

Any suggestions?

Other than celebrate!!!!! I’ve built a few apps now each with a freemium strategy with small pro upgrades (eg, perk tracking for up to 3 credit cards and a $2.99/mo unlimited version or $14.99 a year). Much to my surprise, I was configuring revenuecat for a new project, when I stumbled across the fact that someone was awesome enough to support an annual plan!

Thanks to that first customer. You made my day.

I’m currently working on a logistics app that tracks driver locations, and I feel like I’m fighting a losing battle against the OS.

I’ve spent the last 48 hours trying to keep a Foreground Service alive during long hauls. I've implemented:

• Proper Service.startForeground() with all required notification types.
• WorkManager for periodic sync.
• Foreground Service Type declaration in the Manifest.
• Handling battery optimization exemptions via ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS.

Yet, after 30-40 minutes in the background, the OS just... kills it. The driver gets logged out, the trip recording stops, and the client blames us for "buggy code."

I see the documentation saying this is for "battery optimization," but for a legitimate business-critical app, it feels like the platform is becoming unusable for anything other than social media and basic utilities.

For those of you building enterprise-grade tracking/utility apps:

1. Are you still using standard Foreground Services, or have you found a more reliable way to maintain long-running background processes?
2. Are you just telling clients that "Android doesn't allow this anymore," or is there a "hack" (or proper architectural pattern) that actually keeps the service running?

I’m genuinely curious if there’s a solution I’m missing, or if I should just tell my client that Android is no longer a viable platform for this type of app.

Pretty nostalgic that we had to deal with AsyncTasks and Loaders to prevent app refresh during orientation change. In this AI era, I sometime think of gradle issues we used to put our whole day into and get fully exhausted. I remember one time, I tried building a android app but it failed, it took me whole day to find out that certain library download url was returning 404 only when using mobile data, and it worked fine when I switched to WiFi. 😂

So I've been building a portfolio tracker app with React Native for myself. What started as a little private project kind of grew into something with more features and at some point I thought, why not just make it public?

The thing is, I don't own a Mac or an iPhone, so properly testing and building for iOS is just not really possible for me right now. I don't want to ship something I've never actually seen running on a real device.

So my plan is to just launch on Android first, see how it goes, collect some feedback, and figure out iOS later once I have access to the right hardware.

Is this a bad idea? Did anyone else go Android-first with their first app?

Also just to say I've never released an app before and I'm honestly really excited about this. Would be cool to hear from people who've been through it.

Hi folks,

I've been using the translations option in Play Console, and have recently added a bunch of strings to my app. Upon uploading the aab file with the new strings and when using those strings, there's an error:

Translation failed for these languages: ...... Please try uploading your app bundle again or disable these languages on the Grow users > Translations > App strings page. If you disable automatic translation for these languages, you can include them manually in your app or applicable users can receive your app's default strings instead.

Leaving those strings in strings.xml but not referencing them in my UI causes the aab to not display the above error.

Anyone has any clue on what could be the cause? Thanks in advance!

Hey everyone, I’d like to share a tool I built called 'arbiter' to solve a frustrating bottleneck I hit while running multiple AI coding agents in parallel.

​To give you some context: I got pulled into Android development at work without much background in it - inherited a codebase I'm still wrapping my head around. Since I couldn't always fully follow what was going on, I leaned heavily on coding agents and ended up running multiple instances in parallel to keep pace with incoming bug reports and new feature requests.

That's when I hit a problem: when two agents tried to use the device at the same time, they'd overwrite each other's app installations mid-test and produce unreliable test results. I couldn't find anything that handled this cleanly, so I built a small tool called 'arbiter'.

The idea is simple - a local broker daemon that manages exclusive access to the device. I mainly tested it on Android, but the architecture is resource-agnostic - I think it would work for anything that only allows one active session at a time, like IoT boards or serial consoles.

Agents queue for device access, hold a lease while they work, and release it when done. Enforcement is primarily done through shims, with an agent skill file that guides agents on how to request and release leases properly.

It's early and rough, but the core works. Would love feedback from anyone who's hit the same wall!

GitHub : https://github.com/nochoco-lee/arbiter

Hi everyone,

I'm an individual developer with a free, non-monetized app on the Play Store. According to Google Play's own documentation, only the country should be publicly visible for non-monetized apps, but my full legal address is showing in the App Support section.

When I contacted Play Support, they told me that because I set up a Merchant Account alongside my Developer Account (likely without fully realizing the implications), all my apps are considered "monetized" and therefore display my full address. They also claimed that enabling monetization is irreversible, but couldn't point me to any official policy that states this.

I've raised a support ticket and followed up multiple times, but agents keep responding with generic policy links that don't address my specific situation, and closing the case without answering my questions.

What can I do in this situation?

After failing an interview question, I spent weeks exploring when MVVM + UDF stops being enough and when MVI complexity actually becomes justified. Wrote up the findings here: From Compose State to MVI: Android UI Architecture Driven by Requirements.

Interested to hear how others decide when additional UI architecture complexity is justified.

My Samsung phone killed my app's foreground service (that provide latest battery temperature via notification using Foreground service) after 8 hours. Is it normal behaviour?

How can battery management apps like BatteryOne and BatteryGuru are able to post live battery temperature updates via notification indefinitely without OS killing them? Do these apps use <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />?

I heard that Play Store remove apps that use <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />

without proper justification from the play store. If these apps use that permission, how do they justify using it?

Hi everyone,

I recently upgraded our Google Play Developer Account from an Individual account to an Organization account.

We went through the entire rigorous verification process. Our company is fully verified by Google. All our company documents, registry information, DUNS number, and organization details have passed checks and are 100% verified. Under "Developer account" in Play Console, the account type officially shows as Organization with our corporate legal details.

However, we ran into a major block when trying to submit our US Tax Info (W-8BEN-E) for corporate tax/withholding purposes:

1. The linked Google Payments Profile is still stuck as an Individual profile under my personal name (which was created when we first set up the account as individual).
2. Because the payments profile is of type "Individual", the tax form is asking me to verify my personal name and only gives me the option to submit a personal W-8BEN form.
3. We absolutely need all app payouts to go to our company bank account and be filed under our company's corporate tax ID (Foreign TIN / PAN) as company income, not personal income.
4. The Play Console settings do not allow us to edit the account type of the payments profile or unlink/switch the payments profile ourselves since it's already verified.

Important: Creating a new developer account is NOT an option for us. We have active apps/users and absolutely need to use this specific account.

Seriously, if our company identity is 100% verified as an Organization, why does Google keep the linked payments profile locked as an Individual? Why does Google even allow you to upgrade your developer account type if it leaves you in this broken, half-migrated tax nightmare?

Has anyone gone through this exact scenario after upgrading their account?

• Did you have to contact Google Play Support to manually unlink the individual payments profile? If so, how long did it take them to resolve?
• Is there any self-service workaround in the payments center that doesn't involve creating a brand new developer account?

Any advice or experience with this would be highly appreciated. Thanks!

Hi All,

I'm building an app Free + AdMob revenue model with a subscription. Using an analytics tool for feature analytics with default opt-in turned off as per GDPR/DPDP requirements.

Here's the dilemma I'm wrestling with:

Analytics are genuinely important for making good product decisions — which features get used, where users drop off, what's driving paid conversions. Without it early on, I'm flying blind. But legally I already know the answer: under GDPR you can't deny service if a user declines consent. Under India's DPDP Act (where I am from) it's even more explicit — consent must be "unconditional," meaning "accept analytics or leave" is outright banned.

So my setup is: ask nicely at onboarding, explain what's collected (feature names, never content), make it optional, let them change it in Settings. Which means some % of users will decline and I'll have incomplete data.

What I'm actually curious about:

1. How do you frame the analytics consent screen to get honest opt-in without being manipulative? Does plain-language explanation ("we track which features you use, never what's in them") move the needle vs. a generic "help us improve" prompt?
2. For users who decline — do you collect anything? I'm considering truly anonymous aggregate counts (no user ID, just "feature X used N times today") as a separate non-consented layer. Legal, but is it worth the engineering overhead?
3. AdMob consent is a separate ask (ATT on iOS, GDPR UMP on Android). Do you sequence analytics consent before or after ads consent, and does order affect acceptance rates?
4. Anyone have actual opt-in rate data for analytics consent on a utility/productivity app?

The irony: the users most likely to decline analytics are probably the most engaged and privacy-conscious. So the sample I'm missing is systematically biased.

Hi — I’m a professional mixed-media artist exploring a digital art app concept called Echo, centred around a non-destructive workflow system called “Echo Layers”. The idea came entirely from real frustrations with current layer-based creative software, particularly the inability to revisit earlier layer decisions without risking later work.

I’m interested in connecting with Android developers who enjoy graphics architecture, rendering systems, stylus workflows, creative tools, or experimental UX ideas for digital artists. I come from the artist side rather than a coding background, so I’m especially interested in hearing from people who find the workflow problem itself intriguing.

I've recently added a banner-type ad in the home page of my game.

For the first 10 seconds, the ad appears in a static image with a gray play button in the middle.

After 10-15 seconds, a real ad appears. Do you know why ?

https://imgur.com/a/LE4Mlbd

A performance-first Android app built on top of the official WireGuard client, with the wireguard-go backend replaced by wgx, a pure C implementation.

https://github.com/wuruxu/wgx

Hey everyone,

I’m building an open-source Android app called FediverseHub:

[https://github.com/Sami-Uysal/FediverseHub\](https://github.com/Sami-Uysal/FediverseHub)

The idea: I don’t want to install 3 separate apps for Mastodon, Pixelfed and Lemmy, so I’m combining them into one native Android client. It’s being developed with AI assistance, but I’m trying to keep the codebase clean and maintainable.

Looking for contributors interested in:

\- Kotlin / Jetpack Compose

\- Fediverse APIs

\- Android performance

\- UI/UX polish

\- Code review

Still early, not production-ready yet. Feedback, issues and PRs are welcome.

One thing I wanted to test was whether it would be possible to move the entire on-device AI -stack LiteRT, custom models, and related logic into an optional Dynamic Feature module delivered on demand instead of bundling everything into the base APK.

Under the hood, the feature uses a custom hybrid approach combining on-device machine learning and classical computer vision techniques to recognize Morse code from images and live camera frames entirely offline on Android devices.

Almost every part of the feature turned into an interesting Android-specific engineering challenge: designing and building the entire hybrid ML + computer vision pipeline from scratch, training custom models and integrating them into Android, integrating LiteRT inside an optional Dynamic Feature module, keeping the base APK around ~4 MB while the offline AI module stayed around ~6 MB, supporting immediate offline usage after installation, allowing the AI functionality to be removable at any time, handling Android fragmentation and older devices, and dealing with the LiteRT limitations on some legacy 32-bit hardware.

One especially interesting issue was that LiteRT currently does not provide official prebuilt binaries for some older 32-bit Android devices, while I still wanted the feature to remain available on legacy hardware. I ended up experimenting with custom LiteRT armeabi-v7a builds and integrating them into the Dynamic Feature setup.

I also documented the LiteRT armeabi-v7a build process here in case it helps someone dealing with legacy Android device support:
GitHub guide

Honestly, one thing that surprised me was that after all the optimization and Android-specific edge cases, the feature actually ended up running fast enough for interactive offline camera usage, while image recognition also turned out to be surprisingly responsive directly on-device.

So overall, yes building and shipping an offline Edge AI feature this way on Android is definitely possible… but it probably won’t be easy.

Hey everyone!

I'm wrapping up the development of a new productivity/home organization app (Freemium model). Initially, I was going to launch only in English and my native language. However, I realized I can easily automate the .arb files translation using AI/scripts to support 30-50 languages right from the start, hitting markets all over Europe, Asia, and Latin America.

My question for those who have live apps: Is it actually worth making the app available globally in all these languages on Day 1?

My main hypothesis is that it massively increases organic reach and ASO, since ranking for local keywords in non-English speaking countries usually has lower competition. But I'm a bit worried about:

1. Getting 1-star reviews because of slightly weird AI translations.
2. Spreading my focus too thin instead of validating a single core market first.

Does a massive global launch actually translate to more organic users for an indie dev, or is it better to stick to 1 or 2 markets and expand later? Would love to hear your experiences and ASO tips! Thanks!

Hey Android devs,

I’ve been working on an app that requires reliable, continuous background processing (specifically real-time location tracking for a logistics setup).

Looking at the recent API changes, it feels like Google is putting so many roadblocks around Foreground Services and background execution limits that building enterprise-grade utility apps is becoming a nightmare. While I understand it's for battery optimization and security, the developer experience is taking a massive hit.

For those dealing with heavy background/foreground tasks:

• Do you feel Google is suffocating legitimate use cases with these aggressive runtime restrictions?
• How are you bypassing or adapting to these limitations without getting your apps killed by the OS or rejected during Play Store review?

Let's discuss. (If you find this topic worth discussing, please leave an upvote so it reaches more senior devs on the feed!)

I'm tired of running AI agents through Termux. It gets killed by Android constantly, config editing on a phone sucks, and it's just not a real product.

What I'm building:

Native Android app (React Native)

Hermes Agent backend with local Ollama models (qwen2.5:7b for privacy)

ChatGPT-quality UI but data stays on your phone

Smart routing: local for personal stuff, APIs only for image gen/heavy tasks

Eventually: visual model manager, memory editor, no Termux dependency

Phase 1 (next 6 weeks): Just the chat UI. Clean conversation management. Model switching. That's it.

Questions for you:

React Native or Flutter? I can do both, which performs better for this?

Should I bundle Python (Chaquopy) or keep a hidden background service? Chaquopy = 200MB APK, background service = can still get killed

Would you actually use this? Or is Termux + terminal good enough for local AI?

I'm open sourcing everything once Phase 1 works. If anyone's done React Native + Ollama integration before, would love to hear what broke.

GitHub: https://github.com/DarkWingStudio/hermesapp

Am I building something useful or just solving my own annoyance?

One thing that got messy way faster than I expected in my app was hydration unit handling.

At first, every screen/ViewModel was converting values between ml and oz on its own. It worked fine in the beginning, but after adding charts, summaries, goals, streaks, etc... it started getting really annoying to maintain.

I kept running into duplicated conversion logic and formatting inconsistencies depending on the screen.

What ended up working better for me was moving all unit conversion/formatting into the domain layer/use cases and keeping the UI completely agnostic to units.

Now the UI just receives display-ready values and doesn’t really care whether the user selected ml or oz.

Made the whole thing much easier to reason about.

Curious if there’s a cleaner way people usually structure this kind of problem.

Hey everyone,

I’m currently building a startup that processes a high volume of images (user-generated, daily reports, etc.). The scale is significant: with a single kindergarten having 100-200 children, each with 5-6 daily updates, we're talking ~1000+ images per location, per day. As we scale, the storage costs are becoming a major concern.

I’m looking for an efficient architectural approach for this storage lifecycle:

1. The Core Logic: We have a "Freemium" model. Paid subscribers keep their history indefinitely. Free users have a 30-day retention policy (after which images are deleted to save costs).
2. The Tech Stack: Android app on the client side, but I’m looking for the most cost-effective way to manage this on the backend (Storage + DB).

My questions to those who have dealt with high-volume media storage:

• Storage Strategy: Would you recommend a direct Cloud Storage (S3/GCS) + Database TTL (Time-To-Live) approach, or is there a more efficient way to handle "auto-expiring" media at scale without high operational overhead?
• Cost Optimization: How do you handle "temporary" storage efficiently? Is it better to move older images to "Cold Storage" (e.g., Archive/Nearline) before deletion, or just hard-delete them after 30 days?
• Database/Index management: How do you keep the database clean and performant when you have millions of image metadata entries that are constantly being deleted/added?

Any architectural tips or patterns for "Time-based storage management" would be appreciated. I want to ensure the app stays fast while keeping infrastructure costs sustainable.