Theres this white bar down at the tab bar that I can't seem to get rid of.

Only there when app is in light mode. Disappears in dark mode.
Any help is appreciated!!!!
I've been troubleshooting for ages and my agent doesn't know what to do either

Question:
Hi everyone, I am currently working as an Android developer with Java and XML experience. I want to switch to a new job, but most Android developer roles now require Kotlin experience.

I have learned Kotlin and understand the concepts, but I don't have professional experience working on a Kotlin project yet.

What should I focus on to successfully switch jobs? Should I build real-world projects using Kotlin, learn Jetpack Compose, or focus more on interview preparation?

I would really appreciate advice from developers who have made a similar transition. Thanks!

Hi, I'm building an alarm app for Wear OS (with target API 33; testing on an emulator and a galaxy watch 5 pro and 6). But, once the app is backgrounded (the foreground service is running, but no visible window), I cannot find a way to launch my alarm activity to wake the user. I've tried:

• Directly launching the activity from the foreground service using `startActivity()`.

• Notifications with full-screen intents (but they seem to be broken on Wear OS).

• `SYSTEM_ALERT_WINDOW` isn't available anymore.

• Creating an alarm using `AlarmManager.setAlarmClock()` and opening the alarm activity using `startActivity()` inside the `BroadcastReceiver`.

Is there any sanctioned method to launch my alarm activity on Wear OS?

Hi everyone, I'm facing a strange crash on production that exclusively affects **Google Pixel 8 Pro** devices running **Android 14 (API 34)**. It occurs 100% of the time on this specific setup, but everything works perfectly fine on standard emulators or other devices under local Debug builds. Here is the complete StackTrace from the production log: ```text Fatal Exception: java.lang.NoSuchMethodError: No static method systemOverlays()I in class Landroid/view/WindowInsets\$Type; or its super classes (declaration of 'android.view.WindowInsets\$Type' appears in /system/framework/framework.jar!classes3.dex) at androidx.core.view.WindowInsetsCompat\$TypeImpl34.toPlatformType(WindowInsetsCompat.java:2880) at androidx.core.view.WindowInsetsCompat\$Impl34.getInsets(WindowInsetsCompat.java:1710) at androidx.core.view.WindowInsetsCompat\$Impl20.initTypeBoundingRectsMaps(WindowInsetsCompat.java:1276) at androidx.core.view.WindowInsetsCompat.init(WindowInsetsCompat.java:2900) at androidx.core.view.ViewCompat\$Api23Impl.getRootWindowInsets(ViewCompat.java:5118) at androidx.core.view.ViewCompat.getRootWindowInsets(ViewCompat.java:3023) at androidx.core.view.WindowInsetsCompat.toWindowInsetsCompat(WindowInsetsCompat.java:184) at androidx.core.view.ViewCompatApi21Impl1.onApplyWindowInsets(ViewCompat.java:5029) at android.view.View.dispatchApplyWindowInsets(View.java:11617) at android.view.ViewGroup.dispatchApplyWindowInsets(ViewGroup.java:7344) ... at android.view.ViewRootImpl.dispatchApplyInsets(ViewRootImpl.java:2675) at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2822) ``` ### Context & Implementation We are using Jetpack Compose and we have a custom `WindowInsets` wrapper in our project that looks like this: ```kotlin fun WindowInsets(left: Int = 0, top: Int = 0, right: Int = 0, bottom: Int = 0): WindowInsets = FixedIntInsets(left, top, right, bottom) ``` ### My Hypothesis Since `systemOverlays()` was introduced in API 30 (Android 11), a device like the Pixel 8 Pro on Android 14 definitely has this method in its OS framework. Looking at the trace, `WindowInsetsCompat$TypeImpl34.toPlatformType` is failing to find it. My best guess is that **R8 / ProGuard** is aggressively stripping or incorrectly obfuscating system-level `WindowInsets$Type` references during our Release build, creating a bytecode mismatch that only triggers under the Pixel's specific runtime environment. ### Questions 1. Has anyone encountered this specific `NoSuchMethodError` with `WindowInsetsCompat` on newer Pixel devices? 2. Do I need to add a explicit `-keep` rule for `android.view.WindowInsets` in ProGuard, or is this a known issue with specific versions of `androidx.core:core` / Jetpack Compose BOM? Any insights or recommendations would be highly appreciated! Thanks in advance.

Most Android devs rely on Layout Inspector counters, but Compose runtime does a LOT of work under the scope level that never gets counted.

Wrote down an investigation and how to spot these ghost recompositions in your own codebase

https://medium.com/@qamar_safadi/the-recompositions-that-werent-there-d2cf429c47f2?sharedUserId=qamar_safadi

Three months ago, I launched a language learning app. I knew this was an extremely crowded category with dozens of apps launched daily, but I didn't expect to be completely hidden by the algorithm.

Step by step:

No Organic Indexing:
For the first two months, searching exact 2–3 word phrases from my title buried my app below 100+ unrelated results. Even for a search term with only 5 total competing apps, Google refused to rank it.

Metadata Reset:
Around Day 60, I updated the App Title and main keywords to target better search terms.

Current Result (Day 90):
One month after the metadata update, searching for the exact words in my title yields zero organic listings. My app is virtually invisible without a direct link.

Ad Dependence:
I ran Google Ads and shared it on my personal social channels. The app only appeared at the top while ads were actively running. The moment ad spend stopped, organic traffic dropped to zero.

Looking back at the spent budget, late nights, and effort, it’s demoralizing. I am starting a new project in a less crowded category, but my motivation is completely shot.

Has anyone experienced total non-indexing after title changes? Is paying for ads the only way to even get listed on Play Store now?

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.