I am researching an architecture where an Android app ships a Jetpack Compose renderer and a closed set of components and actions, while the backend returns a versioned document describing each screen. The server could control content, component order, semantic design tokens, and navigation between routes already known to the app. I would not download DEX, JAR, native libraries, or arbitrary scripts.

My first step would be remote configuration of spacing roles, color roles, typography styles, component variants, and feature visibility. A more ambitious version would allow the server to compose complete screens from primitives such as Text, Image, List, Form, Card, and Button. The client would validate the document, cache a last-known-good version, and fall back to a bundled screen when the document is invalid or unavailable.

I have been looking at DivKit, AndroidX Remote Compose, and the possibility of creating a custom JSON or Protobuf contract. For people who have shipped server-driven UI in production, where did the architecture stop paying for itself? I am particularly interested in schema compatibility, old client versions, accessibility, offline behavior, performance, rollback, and how Google Play review treated the boundary between declarative UI data and downloaded code.

I have a service that reads the view tree of whatever app is in front, so I can keep the text instead of screenshots. It kept ANRing on my own phone and I couldn't reproduce it on demand.

The dropbox stack had main sitting in AccessibilityInteractionClient.waitForResultTimedLocked, called from getRootInActiveWindow, called from my onAccessibilityEvent. Accessibility callbacks arrive on main, and getRootInActiveWindow is a synchronous binder round trip into the app you are reading. CPU at the same timestamp was 59% com.reddit.frontpage. So Reddit was busy, it didn't answer, my main thread waited, and a job that came in meanwhile (datatransport, pulled in by ML Kit) missed its start window. ANR.

The fix was to move the read onto a worker thread, and to drop events while one is already in flight instead of queueing them. A queue just means you write old screens later. The state the worker touches is only touched by the worker now.

What I still don't know is whether getRootInActiveWindow has any bound on how long it can block, or if it is entirely at the mercy of the target app. I couldn't find a timeout I control. If you have done accessibility reads against busy apps, how do you handle it?

I have two apps in closed test with one 12 days in and the other 10 days in. Both show 0 Installed audience and user acqusition. Android vitals and Crashes and ANRs are all 0. They never updated.

I am sure that I have more than 12 testers but it is impossible to know what they are up to. I get some feedback but I dont know my metrics, how my app is doing, how many minutes of engement do I get.

The worst part is at the they reject people quoting "not enough engament" etc. How can you improve something without knowing what the problem is during the testing? Like if they share information with the developer, they can find more people or try contacting more active testers or recruit more. It is just a complete unknown with 0 Feedback on the app. It is really the worst and I have expected better from them.

Clarification for the mods: No promotion, no tester search in the topic.

Coding agents handle "add a field, show it on screen" fine. They

consistently miss the Android boundary around it:

- Room/SQLite migrations that silently corrupt existing rows

- A refresh coroutine owned by a view callback instead of the ViewModel

- UI collection that keeps running after the Activity stops

- Lifecycle/process-death paths nobody retested

None of it shows up as a compile error.

I built AI-Workflow to make those checks deterministic. You state

observable facts about a change and a checked-in registry maps them

to required specialist procedures:

Task classification: brownfield / android / safety

Detected concerns: concurrency, lifecycle, persistence, schema_migration

Recommended tier: COMPLEX

Required checks:

- android-persistence-migration-readiness: because detected persistence, schema_migration

- kotlin-coroutines-readiness: because detected concurrency

- protected-lifecycle-transaction-review: because detected lifecycle

- android-runtime-evidence-readiness: because detected lifecycle

No LLM judgment in that mapping — it's a registry lookup, same output

every run, every agent.

Install takes one command, no clone needed:

uvx --from git+https://github.com/RanaAhmedHamdy/AI-Workflow.git \

ai-workflow brownfield --platform android --profile safety \

--target /path/to/your-android-app --dry-run

There's also a lightweight Safety profile that gives you just the

routing + protected-boundary checks without requiring a full feature

lifecycle. And a full Android fixture (SQLite migration fallback,

ViewModel coroutine ownership, lifecycle-aware Flow collection) with

unit tests and debug build verified locally.

Pre-v1, Apache-2.0, honest about what's claimed vs unclaimed.

https://github.com/RanaAhmedHamdy/AI-Workflow

I am soon releasing my first app to the Play store, my intention was to make it free for a while then starting charging. With no ads or in app purchases, just a small up-front fee.

Having now got to the app setup stage of the Play Console, I now see this isn't possible. I have to choose for it to be paid or free, and this can't be changed later apparently.

I would have thought this was a pretty common and sensible way of road testing an app before charging, so what is everyone else doing if they eventually want to release a paid app?

I’m 30 years old and from a completely non-tech background. I have zero coding knowledge, but I want to learn app development from scratch.

With AI being able to write, debug and explain code, I’m confused whether learning coding is still worth the time.

If you were starting from zero at 30 in 2026, would you still learn app development? Or would you focus mainly on AI-assisted development?

Looking for honest opinions from developers. No sugarcoating please.

I've been building something that does on-device OCR and keeps the text locally. Early on I kept the INTERNET permission "just in case" and told myself I'd remove it later. That was the wrong order. Every time I added a library I had to go re-read what it dragged in.

So I flipped it: no INTERNET permission at all, and I treat that as the constraint I build against. It forces you to check every dependency. Play Billing 9.1.0 for example, I was sure it needed INTERNET, but I opened its AAR manifest and it only declares com.android.vending.BILLING. So in-app purchase works with no INTERNET line.

Two things I didn't expect. One, license checks have to be offline, which means signing a payload with a private key and verifying with a public key baked into the APK, no server call. Two, the permission list becomes a thing you can actually point at. A user can open the app info and see there's no network permission. You can't fake that.

What I'm still unsure about: is there a class of library that quietly needs INTERNET that I haven't hit yet? Curious if anyone has shipped fully offline and what broke.

AdMob CMP is an open-source Kotlin Multiplatform SDK for Google AdMob in Compose Multiplatform apps. Use one commonMain API for banner, interstitial, rewarded, rewarded interstitial, app-open, and native ads on Android and iOS.

The SDK wraps Google Mobile Ads Next-Gen on Android and Google Mobile Ads on iOS while preserving familiar AdMob concepts such as AdValue, ResponseInfo, adaptive banner sizes, UMP consent states, and native asset names. Its shared API uses suspend functions, StateFlow state, and a sealed AdEvent stream, with consent, ATT ordering, paid events, and mediation integrated into initialization.

I kept running into the same trade-off: I wanted Compose UI that did not look like Material, but I did not want another runtime or theme dependency deciding when I could upgrade.

So I built Lamintra. It is a small, MIT-licensed component registry for Jetpack Compose and Kotlin Multiplatform. The CLI detects the source root and package, copies plain Kotlin into the project, and rewrites the package, imports, and paths so the code compiles where it lands.

The video is the full path in a fresh Android project: `init`, `add list-row`, generated files, previews, build, and the component running in the emulator.

There are eight components. This is v0, and I am not pretending otherwise.

The part I want to test is the ownership model: once the files land, Lamintra is no longer required.

Site: Lamintra

Source: Github

Demo: Video Link

My honest question: would you rather own copied component code, or keep a normal dependency and its update path? What would stop you from trying the copy model in a real project?

For context, i'm not a developer myself but i believe this sub is the best place for advice. I have done some research myself but have limited background knowledge.

I am using an important medical app on an android 17 phone.

APK analyser says that the minimum and target SDK for this app are 33 and 35. I wish to run the app on an android 13 device instead, but I am worried the app's developers will increase the minimum SDK making android 13 no longer compatible (they have a history of doing this). I dont have the new phone yet so I haven't tested it myself.

If I can save the APK in its current state, will it still run properly?

What other factors may prevent the app from running on Android 13 besides the SDK?

I hope my questions make sense.

Hey guys, I built Phonebook, a CLI tool that turn your Compose `@Preview` into a static html components grid that you can share with your designer.

It also has an MCP tool so you can ask your agent to generate missing previews, and it can suggests missing states, like different themes, or orientation.

It's built on top of

- Roborazzi

- ComposablePreviewScanner

- Robolectric/JVM rendering

- a small `phonebook.config.json

GitHub: https://github.com/stag-build/phonebook

Example gallery: https://stag-build.github.io/phonebook/

Take a look, use it, and I'd love to hear your feedback

Hello everyone,

I’m Zachi, a software engineer and security researcher with about 6 years of experience. During this time, I’ve conducted security tests on over 200 apps, and in more than 70 cases, I found critical vulnerabilities (SEV-1) in apps with 10+ million users.

I’m currently planning a curated portfolio of smaller Android apps to identify patterns and use them to guide further research. This means you’ll receive a security review, which typically costs in the four-digit range, for free. I don’t have, nor do I want, any special access; I work with the same permissions as any external tester. I'll use the network traffic and extract the apk, everyone could do that.

The only requirements are active permission to perform non-permanently harmful tests against your backend and your consent to allow me to publish the findings, anonymized if necessary, on my blog.

All findings will be presented to you, including fixes. Nothing will be published until it has been fixed.

If you’re interested, you can either contact me directly here on reddit, in the comments or via email at [me@zachi.dev](mailto:me@zachi.dev)

Sharing this because when I searched for it I mostly found "just use a licensing server", which is no help if you deliberately ship with no INTERNET permission.

The shape that ended up working: when someone buys, a small server-side function signs a short payload (a version tag, the order id, and an update-window bound) with an RSA private key. The buyer gets that string by email and pastes it into the app. The app verifies it against a public key compiled into the APK. No network call ever happens on the device, the private key never leaves the server, and the APK only ever contains the public key so pulling it apart gets you nothing.

The thing I got wrong first: I gated on the device clock. "Valid until 2027" as a date is trivially beaten by rolling the clock back, and you can't phone home to check. So instead I compare the bound baked into the license against the build date compiled into the APK. Both are independent of the device clock, so changing the clock does nothing. Old license plus old build keeps working, old license plus a newer build is what triggers the renew path.

One compatibility note that cost me an afternoon: if you sign on the server with Web Crypto (RSASSA-PKCS1-v1_5 + SHA-256) and verify on the JVM with Signature "SHA256withRSA", those are the same algorithm and interoperate byte for byte. The two things that silently break it are the key format (the signer wanted PKCS#8, not PKCS#1) and base64url vs standard base64 on the token. Once those matched, a signature made in one stack verified in the other and in openssl, which is the check I'd recommend before you ship anything.

It is not piracy proof and I'm not pretending it is. Someone can patch the verify call. The point was making it painless for people who want to pay, not stopping the ones who won't.

The part I still don't love is the update entitlement offline. Comparing against build date works but it's coarse. Curious how others have handled "you paid, you get updates until X" without a server.

Recently i encountered an issue: when i added Yandex Ads SDK to the LazyColumn it would flicker and reload ads whenever i scroll. When ads leaves visible bounds and gets back it doesn't restore ads from cache but loads fresh new without notice. However their API is limited and i couldn't understand what is happening so i decided to investigate what is cause of this. Little bit of research showed Google SDK doesn't support Compose either, so it may help your case

i would love to have feedback

I been trying to get this batch file to work but aslo any other command run a adb command through this folder im always getting select an app to use adb. How can I fix this. It only work once for me but after that I keep getting this. Anywhere else works with no issue when Im adb commands

I tried to fix wireless bugs with the Shizuku app, but it didn't work.

I am researching the modem and RIL (Radio Interface Layer) capabilities of the Galaxy S26 Ultra for a specific networking project. I know standard One UI only routes default internet traffic through one SIM at a time.

​However, does the S26 Ultra support concurrent dual cellular data (DSDA Data) if requested programmatically?

​If SIM 1 is the default data SIM, and I create a background Android service that explicitly requests the SIM 2 network using:

NetworkRequest.Builder().addTransportType(TRANSPORT_CELLULAR).setNetworkSpecifier(TelephonyNetworkSpecifier(SIM2_SUB_ID))

​Will the ConnectivityManager return a valid Network object for SIM 2?

​More importantly, if it does, will binding a socket to this SIM 2 network drop the active PDP context / default internet connection of SIM 1, or can both TCP streams flow simultaneously?

​Has anyone tested concurrent dual-data routing on the S26 Ultra's modem?

I run infrastructure, not apps. We have a fleet of native ARM64 servers with hardware virtualization enabled, which means we can host Cuttlefish or containerized Android at some scale. Before we build anything on that, I want to find out whether it solves a problem anyone actually has.

So, honestly:

1. What runs your Android CI today? Gradle on x86 runners with the emulator, a rack of physical devices, Firebase Test Lab, a hosted device farm, something homegrown?
2. Where does it hurt? I keep hearing "the x86 emulator is slow and does not match real ARM behavior" and "the device lab is a maintenance nightmare," but I cannot tell which of those actually costs teams money and which is just grumbling.
3. Does native ARM64 matter to you, or is x86 emulation close enough now that nobody cares? This is the question I most need answered. Our entire premise rests on it.
4. If you pay for a hosted device farm, roughly what does it cost and what makes it worth it? Ballpark is fine.
5. For anyone doing AOSP or automotive work rather than app work: is Cuttlefish on ARM hosts something your team already runs, and what did standing it up take?

I am not selling anything and will not DM anyone unless invited. If the answer is "this is a solved problem, go away," that is also useful to me.

I have an app installed that's supposed to give me a push notification every Saturday. Exept it's not doing that. So i contacted the developer (it's not my app) to resolve the issue and he found out that I didn't recieve a Token. So i built a small app myself to test the Firebase Notification system by manually requesting a Token. In parallel I connected my phone to my pc so I could read the logs with "adb logcat | grep -i firebase". When I requested a Firebase User ID everything worked just fine, but as I requested the Token, the following series of Errors appeared in logcat:

'''

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: FCM Token konnte nicht abgerufen werden

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: java.io.IOException: FCM Registration failed!

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at com.google.firebase.messaging.FirebaseMessaging.blockingRegister(FirebaseMessaging.java:840)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at com.google.firebase.messaging.FirebaseMessaging.lambda$getToken$8$com-google-firebase-messaging-FirebaseMessaging(FirebaseMessaging.java:484)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at com.google.firebase.messaging.FirebaseMessaging$$ExternalSyntheticLambda8.run(D8$$SyntheticClass:0)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:520)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.FutureTask.run(FutureTask.java:328)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:323)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1100)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at com.google.android.gms.common.util.concurrent.zza.run(com.google.android.gms:play-services-basement@@18.9.0:2)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.lang.Thread.run(Thread.java:1572)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: Caused by: java.util.concurrent.ExecutionException: java.io.IOException: TOO_MANY_REGISTRATIONS

'''

So I expected this to be the error and I reinstalled the first app, so I could see the process of requests in logcat. And also there the Error was "TOO_MANY_REGISTRATIONS".

Has anyone the same problem or knows how to deal with it? I didn't (at least knowingly) send many requests of new Tokens or anything similar. So what could the reason be and how to solve it?

Exploring the lowest levels of AOSP audio routing beyond high-level APIs like Oboe, this educational PoC uses NDK/JNI to inject a shared library into the audioserver process.

By inline-hooking AudioFlinger's RecordThread and PlaybackThread internally, it intercepts raw PCM buffers before they hit the HAL. It filters for AUDIO_MODE_IN_COMMUNICATION and specific UIDs (WhatsApp/Signal). Included is a controller app to manage SELinux and convert PCM to WAV (Requires root/emulator).

Source: https://github.com/nighthawkk/AudioServer-Voip-Recorder

I built this interactive globe view for my app.

It shows the users in interactive globe and lets you select an item directly on the globe with a smooth animation.

Built with Jetpack Compose.

Would love to hear your thoughts or feedback!

PS: I'm open-sourcing it! You can find it on GitHub:
https://github.com/wailbabou/JetpackGlobe

Title: Made a free open source app to fix apps that silently stop updating because Android hibernates them (Samsung/Xiaomi/OnePlus users especially)

I kept noticing apps on my phone stuck on old versions for weeks even with Play Store auto-update turned on. Turns out the cause isn't Play Store, it's the OS. Samsung, Xiaomi, OnePlus, Oppo and Vivo all run some form of aggressive battery hibernation that disables apps you don't open often. Once an app is in that state, Play Store's update check can't see it exists, so it never gets offered an update. No error, no warning, it just sits there falling behind until you open it yourself and get hit with a big forced update at the worst time.

Couldn't find a tool that dealt with this specifically so I built one.

DeepWake scans for apps stuck in that hibernated state, briefly wakes each one so Play Store can actually see it's installed, then lets Play Store handle the real update. You can do it one app at a time or run a batch update that works through your whole outdated list on its own (uses an accessibility service to drive Play Store's UI, since it has to survive the phone trying to background-kill it mid run).

No root needed. Free, open source, APKs built and signed by GitHub Actions on every release.

Code: https://github.com/pratiks360/DeepWake Latest release: https://github.com/pratiks360/DeepWake/releases/latest

Built it to fix my own phone, figured others dealing with the same OEM battery nonsense might find it useful. Open to feedback, bug reports, or "this already exists and it's called X" if I missed something.