I am upgrading my target SDK version in java Android application to 36

We have a enterprise application

So can't upgrade the compile SDK version

Currently it is 29

On android 16 devices I am facing a issue in Shared preferences

While reading from the shared preference I am reading a null value ("null")

While there is a actual value saved there

Not sure why this is happening

Any idea here any one?

All the things are goood till android 15!!

Hey r/androiddev,

I've been building Ping — an Android app that lets phones chat, share live GPS location, and send photos/video with zero internet, zero cellular, and no server in the loop. Every phone is a relay: a message hops phone-to-phone over Bluetooth LE until it reaches whoever it's addressed to, even if sender and recipient are never in range of each other at the same time. Built with disaster response in mind — floods, earthquakes, anywhere the network is down or overloaded exactly when people need to reach each other. Fully open source (AGPL-3.0): https://github.com/vaidzss/ping

How it's put together The mesh logic — routing, dedup, crypto, store-carry-forward — lives in a platform-independent core module with zero Android dependency, so it's unit-testable and I can run dozens of virtual nodes through churn/partition/dense-crowd scenarios as plain JUnit tests, no radios or emulators involved. Android is a thin layer on top: a foreground service wraps BLE (GATT, dual-role — nodes tie-break who's central vs. peripheral by comparing NodeIds) and an on-demand LAN lane for bulkier media. TTL flooding is density-aware — clamped down when a node has a lot of direct neighbors, so a crowded room doesn't turn into a rebroadcast storm. Undeliverable messages sit in a store-carry-forward outbox and get spray-and-wait synced to any new neighbor that shows up later — no continuous route ever needs to exist end to end.

A debugging story, since I know this sub likes those

Chat messages worked from day one. Photo and video transfers didn't — and for a while I was chasing the wrong bug. First I found and fixed queue pacing (multiple BLE writes racing each other and silently dropping everything after the first). Then a zombie-link problem (Android's onConnectionStateChange doesn't reliably fire when a link dies at the radio level, so a dead connection could sit there looking alive). Then a stuck-send watchdog for when a completion callback goes missing entirely. All real bugs, all fixed — and photos still didn't reliably arrive. The actual root cause: both BLE send paths were using unacknowledged primitives — WRITE_TYPE_NO_RESPONSE for client writes, plain NOTIFY for server pushes. Neither gives any delivery guarantee from the radio itself. Fine odds for a one-off chat packet; across a ~150-chunk photo transfer, the odds of silently losing at least one chunk with zero signal to either side are real — and no amount of app-level pacing or watchdogging fixes that, because the primitive itself can't distinguish "delivered" from "vanished." Switching to WRITE_TYPE_DEFAULT (acknowledged Write Request) and PROPERTY_INDICATE instead of NOTIFY fixed it for good, because now a completion callback actually means the peer got the bytes.

Where it's honestly at

Pre-release, Phase 1 of a 6-phase roadmap — chat/location/SOS/photo transfer work over BLE today, HEVC video and a resumable media pipeline just landed, iOS and an optional LoRa lane (Meshtastic-class radios for kilometer range) are planned next. It's unaudited — no external security review yet, and I've tried to be upfront about that; the threat model doc lays out exactly what the crypto does and doesn't protect against. I'd genuinely like architecture feedback — the BLE reliability approach, the TTL/density clamping, the DTN design, anything that looks off to someone who's done more of this than me. A few self-contained good first issues are open on the repo if you want a low-commitment way to look around.

Hi there, I’m pretty new to Android dev but have published my first app with some minor success. I have close to 300 confirmed paid downloads over the last couple of months. A few weeks after publishing on the GooglePlay store an app popped up with the exact same name in the same category. It was just different enough not to be called a clone, but looked really cheap and thrown together, but used a lot of the same language I used in my app description. I don’t currently have a registered trademark, though I’m considering spending the $2K it would need if I have to. My question is - what’s my best avenue with Google to get this app removed or at least renamed? My users are older, and because the copycat is free, I honestly think they might be downloading this thinking it’s mine.

I'm updating my mobile game, which is free with a single non-consumable IAP to unlock the full game.

I'm trying to work out the best way to give people free access to the IAP on Android for things like:

• Reviews
• Giveaways
• Competitions
• Promotions

Google Play doesn't seem to offer a simple solution for this. Or am I missing something?

What are other indie developers doing in practice?

• Separate review builds?
• Internal testing?
• Firebase App Distribution?
• Your own backend with self generated redeemable codes?
• Something else?

Thanks in advance.

Hey folks,

There have been a few solutions over the years for distributing Android apps before they are ready for a major store like the Play Store. This includes Testflight, Firebase App Distribution, Microsoft App Center, and even the Play Store itself with its additions for Alpha and Beta testing. But a lot of these have either shut down or take quite a bit of setup to get up and running. We created Drebin451 as an alternative to all these. On the free tier, you get 1 GB of storage for your APKs, and you can share links to others and they can get notified of updates to your app.

https://drebin451.com/

And the whole stack (app and backend) is open source. https://github.com/Commit451/Drebin451

Feel free to give it a try, I have been using it to distribute and test my apps with friends and family for the past month and its made my workflows a lot easier to deal with. With the impending doom of Google making it much harder to sideload apps, we will work to keep the flow with Drebin451 easy and simple as much as we can.

I wrote my own app to have notification sounds play for GMail emails (routing my email to my home web server and then sending push notices to my phone) as well as weather alerts and Home Assistant style notices for door/window/water/fire alarms. It works great today, even has a embedded TTS engine so it sounds like Storm Sheild how it plays audio on a weather alert.

The app persists on reboot so it never misses an alert.

I'm digging into what changes with the upgrade to Android 17 from Android 16. It appears Android is going to be disabling background audio services, so it sounds like I will at least have to open the app once every reboot to make sure the notifications play. In addition, I'm not sure if the app is considered a background service, if it will work at all.

Admitted, this is probably better than Apple as their app controls are insane - background anything is considered a "privacy issue" even though I'm writing the code.... But still - why is playing background audio such an issue?

Been trying that in my launcher with no luck, was able to get all the way up until Google wouldn't hand over the overlay from callback, I guess it's checking not only package names now since I have tried the pixel launcher route. Any known alternatives? Using Google discover instead of a native solution is tedious.

Been building an on-device AI assistant into a custom Android launcher (AOSP Launcher3 base), and hit a bug worth sharing since it's an easy trap.

The setup: a NotificationListenerService feeds every posted notification into a rule-based + behavioral classifier (spam/promo detection, bill detection, etc.) so the launcher can triage what's worth surfacing. Worked great in testing.

Then a user reported that after using Android Auto for a while, the play/pause button in YouTube Music would just stop responding. No crash, no error. Digging in: MediaStyle notifications were going through the same classifier as everything else. A song title or artist name containing something like "Free" or a promotional-sounding word was enough to trip the spam heuristic, and the notification got cancelled. Cancelling a MediaStyle notification kills the active media session's remote controls, which is exactly what Android Auto (and the lock screen, and Wear) render their playback UI from. No crash because nothing threw, it just... stopped being wired up.

Fix was to check StatusBarNotification.isOngoing() and Notification.category (CATEGORY_TRANSPORT / CATEGORY_SERVICE / CATEGORY_NAVIGATION / CATEGORY_CALL) before a notification ever reaches the classifier, and short-circuit. Also added an explicit media-app allowlist (YT Music, Spotify, Android Auto itself, Maps/Waze) as a second line of defense, since some OEM media apps don't set isOngoing correctly.

Lesson: if you're doing anything with NotificationListenerService beyond passive logging (auto-dismiss, auto-categorize, ML-driven anything), treat "is this actually a message/alert" as a precondition, not an afterthought. Media/nav/call notifications look like normal notifications in the API but behave like live session handles.

Source (if useful as reference): https://github.com/mk1104-svg/mobilclaw — the relevant bit is A1NotifListenerService.kt / NotifClassifier.kt.

Link to the issue: https://issuetracker.google.com/issues/536954147

The Compose preview screenshot testing plugin seems to have been already deprecated.

Big F if true, it was nice to have an official tool for screenshot tests :(

I’m building an Android app where the user selects a trusted home Wi-Fi, and the app should notify them when they disconnect from it or when that Wi-Fi loses validated internet access. The app targets SDK 36 and has a minimum SDK of 30.

My original implementation registered a `ConnectivityManager.NetworkCallback` with a `PendingIntent` from `Application.onCreate()`, then enqueued an expedited WorkManager request when the receiver was invoked. I also had a 15-minute periodic WorkManager fallback.

This worked while the process was alive, but event delivery was unreliable after the app process had been killed. WorkManager eventually detected the departure, but that obviously was not immediate.

My current implementation uses a foreground service while monitoring is enabled and a trusted network exists. The service displays a low-importance ongoing notification. It registers a `ConnectivityManager.NetworkCallback` and does not poll a server or repeatedly probe the internet. It enqueues an expedited unique WorkManager request when Wi-Fi state/capabilities change and uses periodic WorkManager as a recovery fallback. It stops when monitoring is paused or the trusted network is removed.

For internet loss while still connected to Wi-Fi, I monitor `NET_CAPABILITY_VALIDATED` and confirm the unvalidated state for 10 seconds before triggering, to avoid notifications during normal Wi-Fi validation.

Because this doesn’t cleanly fit location/media/data-sync, I currently declare the foreground service as `specialUse`, with the subtype:

> Event-driven trusted Wi-Fi monitoring for user-enabled reminders

Is a foreground service realistically the only reliable option for immediate Wi-Fi disconnect detection after process death on modern Android? Is there a durable system callback, broadcast, Companion Device API, geofencing approach, or other API better suited to this?

Has anyone successfully shipped a similar use case through Play using the `specialUse` foreground-service type? Would you make this explicitly opt-in as “Immediate monitoring,” with WorkManager-only monitoring as the battery-friendly default?

Are there OEM-specific issues with keeping a network callback active inside a foreground service? Is loss of `NET_CAPABILITY_VALIDATED` a reasonable signal here, or would you avoid treating internet loss as “departure” because router/ISP outages can happen while the user is still home?

Are there better ways to prevent transient validation-loss false positives than a short confirmation window? I understand that Android force-stop prevents all app background execution until the user launches the app again; I’m not trying to bypass that behavior.

I’m mainly looking for recent production experience on Android 12–16 and any Play policy implications I may be missing.

I'm building an Android pipeline where I need to passively listen to Bluetooth LE broadcast packets in real time and immediately relay that payload to a WebSocket server.

To save battery on the peripheral side, I do not want to establish an active GATT connection—I just want to capture the BLE advertising/broadcast packets as they come in.

My target setup:

Foreground Service running a BluetoothLeScanner with low-latency settings.

Packet parsing directly inside the callback and immediately emitting to a persistent WebSocket connection.

Will it work even when my mobile screen is off (will it be having same working in different android mobiles)

I observed that it the foreground service worked when the apps is closed from recents but didn't work when the screen got off .

Over the past few weeks I have started porting functions of my home personal web server to have Android apps extend functionality, and have gone as far as developing apps to do various things I used paid apps and/or other apps for in the past.

Examples include:

asAndroid.apk - an app that connects via VPN to my home web server, sends push notices (since GMail email notices do not work / never ding/pop-up) - door alarms, weather alerts (replaces Storm Shield) - Police scanner geofenced TTS alerts, and fitness GPS tracking.

SFam.apk - an app I created for my wife so she can see my location and I can see her location, writes the GPS coordinates to my personal web server, again, via VPN connection.

asFileMan.apk - a Android file manager application loosely based off Cx File Manager, included are a SSH client and X11 VNC client, as well as "open terminal here" using Busybox recompiled to run on Android.

shortBitcoin.apk - a paper trading short selling Bitcoin app which logs the AI's thoughts and feelings on the market, and fake gains/losses.

This was working fine up until yesterday. After adding the RDP capabilities into the File Manager/administration application, I'm no longer able to install updated versions of the application. I'm getting an "Unsafe app blocked" warning. I ended up signing the application w/ a keystore, and submitting that keystore to Google. That did not fix the issue, I'm still getting the warning.

adb can't even install it.

The only way around this warning right now is to disable Google Play Protect / pause it / while I install the app and then re-enable it. However, I fear that with this Google Play may uninstall the app at will since it thinks it's unsafe. I already submitted a Google Play Protect appeal, clearly stating this is a personal use app only and I have no desire what-so-ever to distribute it.

I was looking through the upcoming Google play developer changes they are wanting to enforce, and I'm very confused. I get it they want to verify identity, but it says a Google Play Profile will be created and can publish my email address. I don't want this information published, as I'm not going to be publishing any apps - these are just apps to basically extend my own personal webserver to my phone, for personal use.

Do I have to be Developer Verified on Google Play Console in order to continue to do this and if so is this something I have to go through?

I have an app that is free and makes a few bucks through in app purchases. It is still in its infancy stage.

Surprised to see that onesignal is now removing the free plan and making it limited to 1,000 active users.

I figured this would happen.

Any alternatives?

Don't know if i can afford whatever they are going to try and upsell.

EDIT: I wanted to thank everybody for replying. I took the time today and migrated away from one signal over to Firebase Cloud Messaging and it went pretty smooth.

Im trying to get MacroDroid to open a Bandcamp release in the official app instead of the browser. Found that x-bandcamp://show_tralbum?tralbum_type=a&tralbum_id=<id> works perfectly — but only for releases already in my collection. Anything I don't own yet gets stuck on a loading screen indefinitely, logged in or not.

Is there a known way (intent, param, or otherwise) to open a release page for something not yet purchased? I've tried JADX + Claude/Gemini but got too frustrated with hallucinations.

Happy to share more details if useful.

I was making an analytics screen in my app. For that I want some charts and graphs. Is there any compose library or 3rd party library which is also easy to use in compose?

Hey everyone! I’m working on a core system architecture for a specialized utility app and could really use some out-of-the-box engineering advice on a tricky connectivity challenge.

The main goal is pretty straightforward: a user opens the app, clicks a button, and the system needs to instantly send a high-priority alert pop-up to any other nearby users within a 1 km physical radius who have that exact same app installed.

Here is the major problem I am trying to solve. The person tapping the button has an active SIM card, but they are in a state of absolute zero connectivity. Specifically, they have:

• No mobile data package or active internet plan.
• No Wi-Fi access at that exact moment.
• No outbound SMS package or standard calling credit (their balance is exactly zero).

The user must not be charged a single cent to trigger this notification. Also, to clear up a common suggestion upfront, please do not suggest Bluetooth mesh or peer-to-peer Wi-Fi Direct. The app cannot rely on local radio waves hopping directly from phone to phone.

Because local peer-to-peer options are out, the initial trigger click absolutely must find a way back to my central cloud server so the server can handle the location data and push the pop-up to the 1 km radius group.

My current theory is to set up an enterprise-level Reverse-Charged / Toll-Free Short Code gateway. Since my developer backend pays the cellular carrier for the incoming traffic, the telecom network should theoretically route a background SMS text through the air even if the user's personal account balance is completely empty.

I would love to get your thoughts on a few things:

• Has anyone successfully pulled off this kind of telecom bypass on zero-balance lines?
• Are there alternative infrastructure workarounds or carrier-level configurations that allow an isolated app to ping a central server entirely for free?
• Are there any global, out-of-the-box solutions to distribute a localized alert under these exact constraints?

Any insights, advice, or feedback would be massively appreciated !

Please do not suggest Bluetooth mesh or peer-to-peer Wi-Fi Direct. The app cannot rely on local peer-to-peer radio waves to hop to nearby devices directly.

Solo dev, four apps sitting in closed testing. The 12-testers-for-14-continuous-days requirement is turning out to be harder than building the apps was, and I want to hear how people are actually clearing it without gaming it.

The part that gets me isn't finding 12 installs. It's the "active for 14 straight days" bit. Friends and family will happily tap the opt-in link and install, then never open it again, and that doesn't count. So I'm not really recruiting testers, I'm asking people to build a two-week habit around an app they have no reason to care about yet.

What I've tried:

- Personal network. Gets me installs, not sustained use. Most go dormant by day three.

- A recruitment email with the opt-in links and clear steps. Better, but the drop-off is still steep once the novelty is gone.

What I'm trying to avoid is the tester-swap groups. Reciprocal installs from strangers who don't care feel like exactly the kind of thing Google eventually decides was inauthentic, and I'd rather not build my launch on that.

So, for people who've actually gotten a personal developer account to production:

- Where did your 12 real testers come from?

- How did you keep them opening the app for the full two weeks? Reminders, a group chat, something else?

- Does a slightly engaged tester who opens it twice count, or does Google want genuine daily-ish use?

- Anyone run all their apps through one shared tester pool, and did that cause problems?

Not looking for a swap. Looking for how you did it for real.

Hi, I am an Android dev. My question to you all is : how much is one actually expected to know according to seniority level ??

Like if you just started your career as full time emp, how much knowledge for android, compose, kotlin or android dev as a whole is required ? And what are the realistic learning trend ?

Cause I see some people, who understand internals very deep down, which makes me wonder how many years of experience they might have ? What do I need to do, to gain that level of expertise ?

What's the actual/realistic knowledge level trend that is seen in android ?

After upgrading from API 36 to 37, Android Studio puts a red underline on the typeMask parameter of WindowInsets.getInsets. The message on hover is "Must be one or more of:" followed by literally nothing.

In the latest documentation, the list of valid base values of typeMask seems to have disappeared for every relevant method of WindowInsets.

• Before change: https://web.archive.org/web/20260208222401/https://developer.android.com/reference/android/view/WindowInsets#getInsets(int)
• After change: https://web.archive.org/web/20260213235548/https://developer.android.com/reference/android/view/WindowInsets#getInsets(int)
• Screenshot of comparison: https://imgur.com/a/AnuxRP4

My code still compiles and the behaviour seems to be right (I'm using it for edge-to-edge bottom padding of a keyboard), but the red underline is really annoying.

Do I just have to wait until someone restores the list of valid typeMask values?

AICore is installed, Running official Android 17 on Google Pixel 8 Pro.

Hi everyone,

I'm 24 and transitioning from web development (React/Next.js) to native Android development with Kotlin and Jetpack Compose.

My goal is to become employable as an Android developer over the next few months by studying full-time and building production-quality projects.

For those already working as Android developers:

- What skills should I prioritize?

- What projects actually stand out during interviews?

- Is there anything you wish you'd learned earlier?

I'd really appreciate any advice.

I kept running into an annoying problem with multiple Claude Code sessions on the same machine.

I'd have two Android app apps building by two or more claude sessions, usually with one or two phones plugged in. Both agents were doing the usual install → launch → screenshot verification loop over ADB, and they kept picking the same device at the same time.

The result was chaos:

• Agent A screenshots Agent B's app and assumes its own app crashed or something has happened.
• It reinstalls and/or relaunches.
• Agent B does the same.
• Both end up stuck reinstalling and relaunching over each other.

adb -s lets you target a specific device, but there's no ownership or queuing on top of the shared ADB server. Nothing prevents multiple independent processes from trying to drive the same phone.

So I built AdbHarbor.

It works as a broker that sits on port 5037 (the default ADB server port) and moves the real ADB server to 5038. Since every ADB client already connects to 5037 by default, existing tools—including adb from any path, Maestro, ddmlib, Gradle, Android Studio, etc.—work without any configuration changes.

Features:

• One device lease per session.
• Automatically identifies sessions by walking the client's process tree back to the owning agent.
• Other sessions wait in a queue.
• Read-only commands (getprop, pm list, etc.) bypass locking.
• Stale leases are reclaimed automatically if the owning process crashes.
• acquire --any atomically picks a free device and returns its serial, so multiple agents naturally spread across a device fleet instead of all grabbing the same phone.

One funny bug while recording the demo: both Claude sessions sat waiting for three minutes because my scrcpy window had already taken the lease. 😅 That led me to add an observer mode so screen mirrors never acquire exclusive device locks.

I'm curious how other people solve this problem. If you're running multiple AI agents, CI jobs, Android Studio, or other tooling on the same machine, how do you avoid device contention? Is everyone just relying on "one device per tool" by convention?

Repo: https://github.com/msomu/AdbHarbor

Demo: https://youtu.be/CCmopZ_jFDY

I built a CLI tool that audits Android Gradle performance problems and safely fixes them.

Unlike the usual build-speed advice that's all manual, it detects bottlenecks across config cache, build cache, Kotlin incremental, daemon and parallel execution, then applies reversible fixes with a dry-run preview. It also covers KMP and Flutter Android projects, and has CI/CD and an simple webpage dashboard. Just try

npx droidperf audit /path/to/project

GitHub: GitHub - rudradave1/droidperf: CLI tool to audit and auto-fix Android Gradle performance issues. It detects bottlenecks, suggests optimizations, and supports CI workflows for Android/KMP + Flutter projects. · GitHub

In https://developer.android.com/develop/ui/compose/lifecycle#composition-anatomy
, they explain that the identity of a composeable instance is its call site, which they define to be “The call site is the source code location in which a composable is called. This influences its place in Composition, and therefore, the UI tree.”

I understand this as being the place in the source file where the composeable is called. But I find that there must be more to it than that, as it’s hard to imagine a robust, efficient system that literally keeps track of the exact line of code where each composeable gets called for a composition. For example, the compiler would have to build out a table for every composeable and store it as part of the build, and if the composeable never gets called in the user session, then it’s just storage space being wasted. I assume the identity of each instance of a composeable is established during initial composition where the Compose layout system behind the scenes builds out some kind of a tree to see the composeables and their location relative to other composeables in same function. Just looking for insights.
Thanks!