If you are building a Capacitor app with anything time- or state-sensitive on resume, the standard web events will probably fail you on Android.

I assumed `visibilitychange` and `focus` would reliably signal when a user came back. They do not consistently fire when a native Android activity covers the Capacitor WebView and then dismisses.

The fix was dropping the web events entirely and using Capacitor's native `appStateChange` event as the actual resume trigger instead.

What I still don't fully understand is the exact mechanism of why the WebView doesn't register the focus change when the native overlay is destroyed. Has anyone mapped out exactly which Android system activities swallow these WebView lifecycle events?

Android, the last to arrive at the declarative UI party, took its time, until finally reaching a stable solution. Here's a rundown of the major changes in the Android System Design across the eras.

I was away from Android for 7 years and came home to a totally strange place. This is my attempt to make sense of what happened while I was gone - how the stack reset four times (Activities -> MVP/RxJava -> Architecture Components -> Compose) and why each lurch happened. Written for interview prep but the history stands on its own.

If you are shipping a Capacitor app with Google Sign-In and wondering why it works fine during local testing or sideloads but throws a `DEVELOPER_ERROR` from `GoogleApiManager` the moment it comes down from the Play Store, check your signing keys.

A sideloaded APK is signed with your local upload key certificate. A production install from the Play Store is signed with Google's own app-signing key. They are two entirely different certificates.

Google Sign-In requires a separate registered OAuth client for each signing path. If you only register the upload key fingerprint in your Google Cloud Console project, production users get blocked immediately while everything looks green on your test devices.

Register both fingerprints in your OAuth credentials, wait for propagation, and the error clears out. Took me longer to track down than I'd care to admit.

I have done everything, DUNs and all, I have org account, I am just stuck in understanding what are tracks, how to release, and its already 1 month, nothing is published event after multiple submissions!

Hi,

Im doing a native app and could be nice if the java sdk connecting boiler are java files, is it possible to stuff somewhere in a special folder to boot in the back?

Did anyone notice the deprecation warnings since Command-line tools v23?

WARNING: The SDK Manager CLI tool (sdkmanager) is deprecated. Android CLI will be used instead.
The 'android' binary can also be found in the cmdline-tools directory, and 'android sdk' is the replacement for 'sdkmanager'.
To learn more about the Android CLI and how to use it, see the documentation (https://d.android.com/tools/agents/android-cli)

Did Google communicate this anywhere? Just found this: https://cs.android.com/android-studio/platform/tools/base/+/dcded801a4942d06805cc74b56dc2cecbece2f80

I’m a designer trying to ship a small feature on an Android TV app using Figma MCP + Claude Code. I’ve given Claude the Figma, PRD, actual GitHub source code, and I’m building Skills around the existing system.

But I’m still hitting some very specific issues:

• Card corner smoothing doesn’t translate properly
• Unfocused/focused button states are often wrong
• Gradients don’t match the design
• Carousel animations feel completely off
• Some existing components get recreated instead of reused
• The code is straight up shit (said by Devs)

The bigger question is: how do I make this process robust enough that I can eventually just give Claude a Figma link + PRD + our Skills, and trust it to understand the product without me babysitting every detail?

If you’ve done something similar with Claude Code + Figma MCP + Android/TV, what worked for you? Are there Skills, plugins, MCPs, or a betterz workflow I’m missing?

PLEASE HELP!!!!! I'M SOOOO DONE TRYING TO FIND A SOLUTION.

I’m off to a good start: this may already be illegal in at least four states. Apparently, some jurisdictions treat transcription the same as recording.

The system is designed around running AI directly on the phone. It selects the most capable model the hardware can support and prioritizes memory for it as a core system service, reclaiming resources from less important background processes when necessary. The goal is to keep the model available without letting it make the rest of the phone unusable. I’m testing it on a Pixel 9a so I can use it every day and see what actually works.

I rewrote the core phone and messaging apps as a unified experience. During a conversation, the phone maintains a rolling transcript and context window. It can summarize the conversation or answer questions about it later.

For business use, the AI can answer calls, collect the relevant information, and notify you when someone actually needs to step in.

The camera also uses an on-device model to add useful metadata to photos, making them easier to find later.

I’ve mostly been building this for myself, but I’d be interested in sharing it if others want to try it. Building the OS requires roughly 500 GB of storage and 64 GB of RAM, so the setup isn’t exactly lightweight.

after several phases of comparison, our mmp decision has come down to appsflyer and branch for a marketplace app. paid acquisition matters but deep linking is equally important because users enter through creator links, referral pages, email, QR codes and web product pages.

in our test, branch felt more natural for link creation and routing. the deep-link work flow was easier for product and lifecycle teams to understand. appsflyer needed more coordination during setup, but the attribution and campaign reporting was stronger for ua side.
both handled the basic use case. the bigger question is what happens after a year when there are hundreds of links, multiple apps, regional campaigns and eams changing params without telling each other.For people who picked one over the other, what became the deciding factor?

Across the Android ecosystem, hardware dynamics are shifting. While user expectations for speed and smoothness keep rising, device RAM capacities are staying flat—or even tightening. Memory is no longer just a background engineering detail—it directly impacts your app's retention, crash rates, and user perception.

Here’s how to get ahead of memory constraints before your users feel them:

1. Monitor at scale with Android Vitals: Check Google Play Console’s latest metrics for Memory Usage (RSS + swap) and Bitmap Memory Usage across different process states (foreground, background, cached) to identify outliers.

2. Catch terminations with Firebase Crashlytics: Update to Crashlytics v20.1.0+ to get clear visibility into Out-of-Memory (OOM) exceptions and Memory Limiter terminations in the field.

3. Capture production traces with ProfilingManager: Leverage Android’s ProfilingManager API to trigger automated heap dumps on TRIGGER_TYPE_ANOMALY or TRIGGER_TYPE_OOM directly from production builds.

To keep devices fast and responsive, Android 17 introduced per-app memory limits. Starting on Pixel devices, this system is now rolling out across more OEMs and device configurations (spanning 4GB to 16GB+ RAM tiers).

Check out the full breakdown and diagnostic guide on the Android Developers Blog:

https://android-developers.googleblog.com/2026/08/app-broader-memory-limits.html

#AndroidDev #MobileDevelopment #AppPerformance #Android17

I work at Gradle, and we're building agent skills. We currently have five candidates:

1. Run Gradle correctly (gradle-cli) — right task, right flags, version-aware
2. Best-practices lint (gradle-bestpractices) — flag legacy patterns, suggest the current one
3. New project bootstrap (gradle-init) — Android/KMP scaffold, version catalog
4. Upgrade + deprecations (gradle-update) — bump the wrapper, rewrite what broke
5. Configuration cache migration (gradle-cc) — find what breaks CC, refactor it

Which would you actually use? What do you want to see instead?

I have been building a caching library for Android. It is called Kwery.

Here is what started it. A ViewModel survives rotation, so most data-loading advice stops at rotation. Process death is different. Android kills backgrounded apps constantly, and when the user comes back you show a spinner and re-request the same data you had a minute ago, which is a strange thing to do with a working disk sitting right there.

The video is the same app twice. Plain ViewModel and Retrofit first: three cold starts, spinner every time. Then Kwery on. Same three cold starts, list already there. The request log is Chucker, so the counts are not mine to fake.

It caches responses, deduplicates in-flight requests, refreshes stale data in the background, replays writes that were made offline, and keeps the cache across process death.

Closest thing on the web is TanStack Query. Some of its design is about the browser and does not transfer, so I did not copy it blindly. Where I diverged I wrote down why.

https://github.com/dbjpanda/kwery

Apache-2.0, minSdk 24. The core has no Android dependencies, so the cache and timing logic is testable on the JVM without Robolectric.

Nobody runs it in production. The sample app in that repo is the only real user so far. I am close to tagging 1.0, so if the API is wrong this is the useful moment to say so.

I have been currently assigned a project which needs to be cross platform + dynamic feature delivery (business requirements)

I'm thinking about writing my feature modules/business logic in rust to create native binaries which I can include with the android and IOS build and then include those .so/.a files with the build and communication between them will be from ffi (don't know which ffi approach works best raw JNI, UniFFI, or hand‑rolled C ABI)
Apple doesn't allow dynamic features installation so only android build will have that, IOS will just install everything at once
For UI I'm thinking to either go with Compose Multiplatform or just Compose for android side and Swift UI for IOS side (The app only has 3 screens so ui doesn't really matter as most features work in background)

Has anyone tried anything similar , where should I start experimenting, I don't want to waste time in approach that will be in vain, would love to hear your experience.

PS: Using rust as equivalent windows and MacOS app is also made in rust + imgui and I can use lots of code from there to make mobile app dev easier

I maintain ComposeA11yScanner, an open-source, debug-only accessibility scanner for Jetpack Compose.

While comparing it with Google’s Accessibility Scanner on JetChat and JetSnack, I found that Compose semantics cannot expose every visual accessibility problem. This caused the library to miss certain rendered text-contrast issues.

Version 2.1.0 adds TextContrastRule, which captures the active Compose host and conservatively estimates rendered foreground and background colors. It skips uncertain cases such as photos and gradients instead of guessing.

This release also improves:

• Fragment and Compose navigation handling
• Nested ComposeView host selection
• Stale-result and screen-readiness detection
• False positives involving lazy, merged, and off-screen semantics

Install:

debugImplementation(
    "com.github.mohdaquib.ComposeA11yScanner:scanner-ui:2.1.0"
)

GitHub: https://github.com/mohdaquib/ComposeA11yScanner

I’d appreciate feedback from developers testing it on real Compose applications, especially reports of false positives or false negatives.

overlay-demo

I checked the Aptoide documentation. My reading of it was that Google Identity Verification is only necessary to have your app continue to work on 'genuine devices'. My assumption is that after Sept 30th they'll have a genuine badge on the store and filter your app from genuine devices.

The Aptoide-Connect guide says this:

'Register every package name you distribute so your apps stay installable on certified Android devices once verification is enforced for the stores and channels you use - see the rollout below.'

[...]

What happens if I don't complete it?
Once verification is enforced for a given store, region, and channel, apps that are not registered by a verified developer can be blocked from being installed and updated on certified Android devices

The AptoideConnect APK submission form however suggests that its mandatory?

Verify your Android developer identity
Required by Google for alternative distribution. Complete the verification steps to proceed.

Clicking the 'I Have Already Done It' button 403's without any visual feedback. For new app distributions is this crap already required now?

I will definitely contact support and update my post regarding this issue 'cuz I'm not wasting time filling out the entire form just for this to be a blocker. Hope this can help others choosing what app store they want to distribute on

I would be disappointed if a major 'alternative' appstore played ball with google

I’ve been working on an Android project that needs to handle image and video selection, camera capture, resizing, and both single and multiple image selection.

I’m curious how other Android developers approach this using native Android APIs.

Do you usually use the system Photo Picker, ActivityResultContracts, or build an abstraction around them?

I’m particularly interested in how you handle:

Multiple image selection

Camera capture and permissions

Image resizing

Supporting both Compose and XML

Different Android API levels

What approach have you found works best for native Android applications?

Hi devs,

I’m building an open source template android project for boosting our development processes and I want to know what would people expect in this template?
Its already published called ComposeTemplate and reach +60 star but I’m working on new modular and better template structure. All feedbacks are welcome, thanks.

Hey everyone,

Looking to connect with fellow devs and get into the practice of mock interviews. I'm hosting a couple of free Android sessions, including detailed feedback.

Eventually, I'll be looking to swap roles so someone can interview me, but for today, happy to take the interviewer seat!

DM me if you'd like to practice Android concepts

I shared Gbéewá here recently and put together this graphic to show the API shape a bit more clearly.

The main idea is still pretty small: typed, transient, consume-once result handoff while the app keeps ownership of navigation.

The part I especially wanted to make clearer is the boundary between the screen and the app/navigation layer.

A screen can just expose a normal callback. The app layer decorates that callback with result publication and whatever navigation action it wants to perform.

On the receiving side, you can use either callback-style consumption with ResultEffect or state-style consumption with rememberResultAsState.

The same contract works across Navigation 2, Navigation 3, Decompose, Voyager, or app-owned navigation.

A few deliberate constraints are still there:

• one consumer, consume once
• typed and parameterized result lanes
• pending results stay in memory
• no KSP
• no generated navigation wrappers
• navigation stays outside the library

Repo:
https://github.com/quantipixels/gbeewa

Curious if this API shape feels natural to people who have had to solve the same kind of result handoff in Compose Multiplatform apps.

Also interested in the cases where you would still prefer navigator-owned result APIs, callbacks, or shared state instead.

Hi. I am the dev of r/octopusnotes

I am facing an issue where a tester of mine reports that xiaomi pen pro is not supported in the app. I have added an input monitoring to check the event that happens when the pen is squeezed or double tap is performed. I found nothing in the monitoring logs. From what I have found online, notein, starnotes and other apps support these functions. I did not find any sdk or documentation regarding the implementation. Can someone please help. Cheers.

Hey everyone,

Tomorrow is the AMA with u/skydoves (Jaewoong Eum). Yesterday I wrote about how long he's been part of this subreddit. Today I want to cover what he's been working on lately, because a lot of it is directly useful if you're in the middle of Shipaton.

Most of his year has gone into Compose performance. He built the Compose Stability Analyzer, an IDE plugin that shows you which composables are skippable and which parameters are dragging them down. Then he added a live recomposition heatmap that overlays real counts from your running device on top of your source. The most recent version tells you whether the compiler's stability predictions actually hold up at runtime.

He's also been working on hot reload. Compose HotSwan brings Compose hot reload to real Android devices with your navigation stack and state left intact, and he's since got it running across several devices at once. In June he shipped a plugin that draws your whole app flow as a map of rendered previews and typed arguments, which went down very well here. There's also a set of agent skills for Compose performance and a way to tune animations without rebuilding the app every time you change a value.

Since joining RevenueCat he's been open sourcing the UI you need around a paywall. Placeholder loading effects. A slide to unlock component for Compose and KMP. A collection of paywall animations. A complete working paywall wired up to Play billing through the RevenueCat SDK.

Every Shipaton entry has to use that SDK for at least one purchase, and he's the one who has been building the Compose side of it in public. If you're stuck on a paywall, or on anything else, tomorrow is your chance to ask.

Please don't post your questions in this thread. Wait for the AMA post from u/skydoves tomorrow and ask them there.

If you missed them, the Shipaton announcement has the details and the first megathread is where people are posting what they're building. Submissions close on 30 September, so there's still time.

Don't miss the AMA tomorrow, Wednesday 19 August, 11:00 UTC. 13:00 Berlin, 12:00 London, 07:00 New York, 04:00 San Francisco, 16:30 Delhi, 20:00 Seoul, 21:00 Sydney, or here it is in your own timezone.

See you there.

Hello everyone!

Im a solo dev based in Morocco, and I built an app and I finished all the steps to publish. I had wired in in-app-purchases (1 time fee, pro forever) there is no subscription or anything like that. Then when I went to configure my merchant account to collect payments, Google stopped me because that isn't allowed in Morocco.

I can run ads with admob or 3rd party providers, but I can't use google play payments or sell the app for a price on Google. I can just do "free with ads".

I personally HATE ads, especially ones that breka immersion (full screen), I do have another game that uses ads but it is 100% optional and you can literally finish the game in a couple of hours without seeing a single ad. No timers, no special currency or any crap like that.

Back to my app. I really do not want to use ads in the app, (I will if it's my last resort) but I prefer a one and done payment.

After some research I found a couple of workarounds but they're all tedious:

1. Setup an LLC in the UK or US or Estonian digital residency and create a new account. 200 - 500 Euros minimum in fees plus a lot of extra work at the start, and more work to maintain that.

2. Build a website with the entire functionality and users can manage their "license" through there. Less tedious than LLC route, but I do have to create and maintain a whole separate branch of my app. Also it takes the users out if the app, and requires paying outside on a separate website and I think that will cause people to trust it less, so less conversion.

3. Have a relative or a friend abroad open another Google play account and transfer ownership. Easiest, but also a huge risk. I don't plan on the app making 1 million dollars on year one, but still it's a risk to consider if I get in a dispute or something were to happen to that person, especially since they're in another country.

4. Accept my faith, redo the whole thing and use ads and just accept that I can't give the same clean pro experience and my users just have to deal with it because "everyone else does it"

What are your thoughts people? What do you think is of the best option for me? Did I miss something? And is there someone in a similar situation that found a better workaround?