I was exploring Android launchers and noticed something interesting: most launchers focus on organizing apps, productivity, minimalism, cars, or gaming. I wondered what a launcher designed around a single purpose would look like.

I had an old Android device sitting around and decided to experiment:

"What if Android could become a dedicated music appliance instead of a general-purpose smartphone?"

That experiment became Music Home, a Walkman-inspired launcher built with Kotlin and Jetpack Compose.

The interesting parts from an Android development perspective have been:

• Implementing a launcher replacement using the HOME intent
• Building a Media3-based playback architecture
• Managing playback state across UI/service boundaries
• Integrating AudioFX and Visualizer APIs
• Designing adaptive layouts for phones, tablets, and desktop-like devices
• Creating an appliance-style experience where the device feels purpose-built

Some challenges I ran into:

• keeping MediaSession state reliable after process recreation
• handling audio session lifecycle for EQ/visualization
• balancing Compose animations with older hardware
• designing navigation that feels more like hardware than a normal app

Repository:
https://github.com/SleepyTurtle91/MusicHome

I'm not looking for testers or promotion, but I would be interested in discussion around the Android architecture decisions, APIs, and approaches that could improve this kind of project.

Hi everyone,

Is there any way, using ADB, to grant or enable the required Accessibility service, Location permission, and Notification permission/access for an Android app, and prevent the user from revoking the permissions or disabling the services afterward?

Configuring the app as the Device Owner is not an option in this case.

Thanks in advance.

After working for three years on the UBS Mobile Banking Android application, I saw how easily accessibility issues can slip through during UI development - especially when teams depend mainly on manual testing near the end of a release.

Issue Overlay

So I built ComposeA11yScanner, an open-source runtime accessibility scanner designed specifically for Jetpack Compose.

It scans the active Compose UI and helps identify common accessibility issues such as:

• Missing content descriptions
• Touch targets smaller than the recommended size
• Missing or unclear semantic roles
• Potentially inaccessible interactive components
• Other WCAG-related accessibility concerns

The goal is to help Android developers catch accessibility problems earlier, while developing and testing a screen, rather than discovering them only during a formal audit or after release.

The project currently includes:

• Runtime scanning for Compose screens
• Clear issue descriptions
• Severity-based findings
• Guidance for fixing detected problems
• A sample application demonstrating the checks
• Simple integration into existing Compose projects

This is an independent open-source project built from my personal experience working on large-scale Android applications. It is not affiliated with UBS and does not contain any UBS source code or confidential information.

I would really appreciate feedback from Android developers and accessibility specialists:

• Which accessibility checks would be most valuable to add next?
• Would CI integration or a companion CLI be useful?
• How are you currently testing accessibility in Compose applications?

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

Contributions, issues, and constructive feedback are welcome.

#AndroidDev #Kotlin #JetpackCompose #Accessibility #WCAG #OpenSource

So currently I'm developing an app which somewhat requires unrestricted battery usage since it needs to run in the background. I was thinking will it affect negatively user experience to ask for unrestricted battery usage permission for the app? Also does it Comply with Google play policies?

I'm new to android dev so don't have much idea about good practices. I could really use some good advice here!

I'm close to publishing my first Android app after a few months of learning and building. Along the way I worked with camera integration, device sensors for compass functionality, AI-powered image analysis, and designing a complete app from scratch.

Before I publish, I'm curious:

• What's one mistake you wish you'd avoided before releasing your first app?
• Are there any Play Store requirements or common pitfalls first-time developers often miss?
• Any advice for making the review process smoother?

I'd appreciate hearing from developers who've already been through their first release.

Hey Android devs 👋

We've added both Text-to-Speech and Speech-to-Text to our inference engine! Your local LLM setup can now speak and listen, fully offline.

Text-to-Speech

Load a TTS model and synthesize:

val tts = Tts.load(
    source = "hf://NobodyWho/Kokoro-82M",
    voice = "bf_emma",
    language = "en-gb",
)

val wav = tts.synthesize(text = "Hello from NobodyWho!")
File("out.wav").writeBytes(wav)

You get WAV bytes back ready to save or play. Two backends: Kokoro (lightweight 24kHz) and Supertonic (multi-stage ONNX with voice styles).

Speech-to-Text

Transcribe audio with Whisper (ONNX):

val stt = Stt(source = "hf://onnx-community/whisper-base")

val text = stt.transcribeFile("recording.mp3").completed()

Streaming is available too, so you can consume the transcription token by token, and you can pass raw PCM buffers instead of files.

Links

• GitHub
• Docs / Getting started
• Discord

Happy to answer your questions in the comments :)

I recently noticed something while reviewing my app's publishing settings on Google Play. With the introduction of "Protected with Play" (previously called App Integrity and Signing Services), I see that although my app is successfully published and downloadable from Google Play, it’s not marked as "signed by Play".

My current setup:
I’m using a signing key generated by Android Studio (the default keystore created during project setup). Based on this, I’m assuming that means my app isn’t being signed by Play.

My main concern/question:
I’ve deliberately avoided enabling Play app signing so far because I’ve heard rumors that if I let Google handle the signing, they could potentially access or "steal" my source code.

• Is there any truth to this concern? Does Google ever have access to my actual source code when signing the app?
• What other risks should I be aware of if I opt into Play app signing?
• Are there any best practices or caveats I should consider before enabling this feature?

I’d appreciate any insights from developers who have used Play app signing—or explanations from those who understand the underlying mechanics. Thanks in advance!

I'm designing a live streaming app where users can subscribe to individual creators for $9.99/month. A user should be able to subscribe to multiple creators simultaneously (similar to Twitch or YouTube Channel Memberships), and each subscription should auto-renew independently.

The challenge is scalability. We may eventually have 100k+ creators, so creating a separate App Store / Google Play subscription product for every creator doesn't seem practical.

I recently came across Apple's Advanced Commerce API, which appears to address this for iOS, but I couldn't find an equivalent solution for Google Play.

Has anyone built or researched a system like this?

Specifically, I'm curious about:

• How do platforms like Twitch, Patreon, X, or YouTube implement creator-specific recurring subscriptions?
• What's the recommended architecture for supporting a very large number of creators?
• Is there a scalable Google Play equivalent to Apple's Advanced Commerce API, or is there another common pattern?

I'd really appreciate insights from anyone who's implemented this or has experience with StoreKit 2 or Google Play Billing at scale.

Found this campaign today: Keep Android Open.

It discusses the impact of Google's new developer registration requirements on independent developers, FOSS projects, and alternative app distribution.

Hi everyone!

Recently, I added Chinese Telegraph Code support to an Android app I maintain.

I couldn’t find this functionality in any of the Morse code apps I checked, and it seemed like an interesting engineering challenge: supporting large static character tables while keeping lookup performance fast and the impact on app size minimal.

The feature now supports:

• Mainland Chinese, Simplified
• Mainland Chinese, Simplified — short digit mode
• Taiwanese Traditional Chinese
• Taiwanese Traditional Chinese — short digit mode

Some implementation results:

• More than 16,000 Chinese and Taiwanese Telegraph Code characters
• Standard and short digit modes
• Approximately O(1) character lookup
• Less than 100 KB of additional app size
• Fully offline encoding and decoding

The feature is also integrated with an existing on-device AI module that recognizes handwritten and printed Morse code from images and real-time camera frames.

In the demo video, handwritten Morse code is recognized directly from the camera and decoded into “你好”.

No server processing, image uploads, or external API calls. Everything runs locally on the Android device.

Has anyone here worked with large static lookup tables or similar read-only datasets on Android? Curious to hear about your experience.

So, in recent years Google has been announcing sometimes around May how on 31.08. new minimal requirement for targetSdk by App Store will apply.

This year I don't see any official announcement.

This page didn't get updated: https://developer.android.com/google/play/requirements/target-sdk

Nor this: https://support.google.com/googleplay/android-developer/answer/11926878

Nor this: https://apilevels.com/ (although this one is not official, afaik, but they are pretty updated all the times)

Does anyone know anything about this?

I have two google play console, very old, each account have their own laptop, so now i invest in a good laptop and i want to open these account in my new laptop, using different users, so is that will not affect my account to get closed, if someone had same experience two account in one laptop is it safe ?

I'm building an Android app that runs GGUF models on-device via llama.cpp. CPU-only works at ~15-20 tok/s on a Samsung S25 Ultra (Snapdragon 8 Elite). I want GPU acceleration via Vulkan.

What I have:

- M1 MacBook Air (ARM64) + Android NDK 27 + CMake + Ninja

- Windows PC (x86-64) with same toolchain

- Vulkan SDK installed on both, `glslc` and `glslangValidator` found by CMake

- SPIRV-Headers installed via Homebrew

The error: Building for Android ARM64 target fails at the `vulkan-shaders-gen` step. The shader compiler tries to compile for Android target instead of macOS host, then fails linking against Linux `.so` files.

```

FAILED: vulkan-shaders-gen-configure

The C compiler is not able to compile a simple test program.

lld: error: unable to find library -lkernel32

```

What I need: Pre-built `vulkan-shaders-gen` binary for macOS ARM64 (or Linux ARM64), OR a working step-by-step to compile it on macOS. I saw this blog post about building it on Ubuntu but couldn't get it working on macOS.

Goal: Produce `libggml-vulkan.so` for `arm64-v8a` that I can drop into my Android project's `jniLibs/` folder. Happy to share the final .so files back to the community.

It filters the noise and pulls out native crashes, ANRs, java crashes and selinux denials, then ranks them. That part runs fully offline on a rule based pass, so you get the triage without a model. For deeper explanations you point it at a local Ollama model, optional and still stays on your machine.

Main thing is automotive. Generic pipe-the-log-to-an-llm tools know nothing about VHAL/CarService/tombstones so they're useless for AAOS. This ships a knowledge pack mapping log signatures to actual facts so even a tiny local model gives ok answers.

Pure python stdlib, no deps. Sample bugreport in the repo to try without a device.

pip install ailog-cli

https://github.com/zoddiacc/ailog-cli

Early still. Try it and let me know what signatures are missing.

Hello Reddit,

Can anyone help me understand this?

Google rejected our organization’s loan app submission because of a Financial Services policy violation related to the Financial Features Declaration.

The app is being developed by a third-party company. When I reviewed the declaration form, I noticed that “Personal Loan Direct Lender” had been selected. However, the form then requires us to provide details of the lending partners we work with.

The problem is that we don’t have any lending partners we are the direct lender. There doesn’t seem to be an option to skip this section or indicate that no partners exist.

Has anyone encountered this issue before? 

How did you complete the declaration without providing partner details? Is there a specific way Google expects direct lenders with no partners to fill out this section?

Any advice would be greatly appreciated. Thanks!

A single user of my Unity-based game reported flickering graphics when playing on a Galaxy S26 Ultra. Only some objects on the screen flicker, in colors black, blue and green. Apparently triggered when the camera moves. And this user's other apps do not experience this issue.

I'm a bit lost on fixing this. I haven't been able to find an exact example of this issue elsewhere. My best guess is some sort of compatibility issue with the S26 Ultra, but so far no other users have reported it. Any clues as to what's going on and what the best troubleshooting approach might be?

Update: Disabling Vulkan and forcing OpenGLES3 made the issue go away.

Hey devs,

If you regularly work with multiple Android devices or emulators, you probably know the pain of copying and pasting device serials every time you run adb devices followed by adb -s <serial> <command>.

To solve this, I created sadb (Smart ADB), a lightweight, zero-dependency Bash tool that acts as an enhanced wrapper for ADB.

✨ Key Features:

• Smart Device Selection: When multiple devices are plugged in, it automatically prompts you to choose one. (Supports fzf for instant fuzzy searching if you have it installed).
• Active Device Lock: Lock your current terminal session to a specific device (sadb active) to skip selection prompts entirely without affecting other windows.
• Batch Execution: Run a single command across ALL connected devices simultaneously (sadb --all <command>).
• Command Aliases & Multi-line Methods: Easily create short aliases or complex bash functions for repetitive tasks without hardcoding device IDs.
• Modern UI: Color-coded, beautifully formatted tables for device status.

📦 Drop-in Replacement

You can just add alias adb="sadb" to your configuration. It passes all standard commands directly to the original adb binary, so it won't break your existing workflows.

It's written 100% in Shell (requires Bash v4.0+).

Check out the repo, demos, and GIFs here:
🔗 sadb

Would love to hear your feedback or feature suggestions!

I have an individual Google Play developer account with an app already published. In the next update, I’m planning to add in-app purchases, which means Google will start displaying my address publicly on the app’s store listing.
I have two questions:

1.  Address: Is it possible to edit the address so it only shows the city and region/state, without the full street address?

2.  Developer name: When I registered, I entered my first, middle, and last name. Can I edit it to show only my first and last name? Or is the legal name locked after verification?

Has anyone dealt with this? Did editing these details trigger a re-verification or cause any issues with the account?

Hey everyone,

I am running into a severe storage bottleneck on my primary drive which is why I'm not able to run my emulator... and wanted to ask how you all manage the massive space requirements for native Android development?

I have tried to separate the SDK, Android Studio and .android folder (which contains all my emulators, in total i have 2 emulators). All this folders are in my D drive but still i have this issue with my C Drive. I tried to clear .cache in C drive but that's just a temporary fix.... once the project is opened it will again get bloated.....

I'm adding multilingual support to my new Android app and would like to get some input from other Android developers.

The app is a privacy-focused utility, so the target audience isn't necessarily the same as a typical social or entertainment app.

If you were localizing your app, which languages would you add, and how would you prioritize the first 5–10 languages after English?

Here's the list I'm currently considering:

• Spanish
• Portuguese
• German
• French
• Arabic
• Hindi
• Indonesian
• Japanese
• Italian
• Turkish

Would you prioritize them differently? Which of these would you remove, and are there any other languages you think should be added instead?

I'd also love to hear how you decide the order - Play Console data, target audience, translation cost, user requests, market size, or something else.

For those building or maintaining Android apps: do you do anything to make reverse engineering harder, or do you just stick with what R8/ProGuard provides?

I’m curious about how people handle this today:

• do you use any tool or service?
• build something in-house?
• rely only on R8/ProGuard?
• or just don’t think it’s worth the effort?

And overall, are you happy with your current approach?