Google almost gave up on this one, so i decided to build it myself
What works:-

1. IDE and compiler, solved all performance issues with coding and compiling
2. XML previews
3. Jetpack Compose Previews (Had to build the xml and compose viewing library from scratch to support arm64, google did not have that.)

What isn't supported yet:-

1. Android Emulator, you will need a physical device to test.

Known issues:-

1. Gradle project is imported every time you open it in android studio (Fixed, thanks for the comments)

Download link: https://github.com/DevanshSampat/android-studio-arm64-releases

All repositories required for building Android Studio are on my github: https://github.com/DevanshSampat?tab=repositories&q=android-studio&type=&language=&sort=

Enjoy Devs ;)

I just went through one of the most unnecessarily stressful 24 hours of my developer life, and I need to rant about how Google treats its developers.

Because my app generates revenue, Play Console recently went through a routine check regarding merchant payment verification. Fine, I updated everything immediately and submitted it.

But right after, a massive, scary red banner slammed across my dashboard saying:
"Your developer profile will be removed, and all your apps will be removed from Google Play on November 23, 2026."

Underneath that terrifying headline, in much smaller text, it says: "Google couldn't verify your merchant payment method." And deep down in the microcopy, it basically implies that this warning stays active even while your newly submitted info is under review.

Are you kidding me, Google?

I am a partner introducing revenue to your platform, complying with your rules, and your automated system decides to hold a metaphorical gun to my head with a countdown timer to wipe out my entire business, just because your team takes a day to press a review button?

Mixing up "Routine Administrative Review" and "Severe Violation Punishment" into the exact same panic-inducing UI element is peak lazy engineering and toxic UX. For an entire day, I had to stare at a countdown to my apps being deleted, wondering if an automated glitch would destroy years of my hard work.

The verification finally cleared today (it only took about a day) and the warning went away, but the psychological toll and unnecessary anxiety were completely uncalled for.

Has anyone else been absolutely jump-scared by this specific red banner? Google seriously needs to fix their Developer Experience (DX). This is not how you treat people who build your ecosystem.

Something has been rubbing me the wrong way for a while now. I have 3 tracks for my app in Google Play, internal, open beta, production. When deploying changes we go through all 3 tracks with a single binary. I can understand the Open Beta track needing a review, but once that's approved why do I need yet another review to promote that binary to Production? I honestly wouldn't care if the review times were manageable, but I've had multiple reviews take over 2 weeks. When they are reviewing the binary are they expecting different results? Notes about the app that might be affecting the review timelines; it has Android Auto capabilities as well as a Wear OS version.

TLDR; Why do we need multiple reviews on the same binary when promoting between release tracks?

Specifically as an Android developer? I spoke to my mentor about being interested in android development, and he said he thinks I would only enjoy it only if I went to a Big Tech company because it would provide more challenge and chance for cross team collaboration which I enjoy.

It made me want to hear about people's experience working in Big Tech vs smaller or non-tech companies as an Android dev. Which do you prefer?

I'm building an Android app that uses AccessibilityService to keep people on a lock screen during a time window they chose themselves.

I have read Google's Accessibility policy. It says the API can't be used to stop users from disabling or uninstalling an app. I also read over 200 user reviews of an existing app on Play with a strict lock. It's official way out of a session is a paid in-app exit. The reviews suggest a lock only works if it's hard to escape, so I'd prefer no early exit.

My question: does play allow a lock with no in-app exit when the person chose the window themselves? I want to stay within the policy. Has anyone shipped one, or been rejected for one?

I just thought I would post how my play store submission is going, since I am always looking for info and want to help people out that are looking for answers. App store submissions are much more work that I thought.

I just had my iOS app approved last week. Now android. I submitted on Saturday.

It was WAY faster than I expected. Review came back rejected yesterday, Monday morning (India time). Then I resubmitted yesterday too.

Now this morning, already got rejected again. They are WAY faster than Apple, at least for me. But I also realized they are actually testing way more thoroughly than Apple did. I am getting my second fixed submission back now. I will update this post if they review it again right away tonight (India employees seem to do it at 3-4am EST, which is day in India obviously).

It seems the only issues they have are with my Google API scopes I use for some imports from health, sleep, etc... I did get it all approved in the Auth Center, but I guess they dive deep into those in review. It seems they all are okay, I just have to show them proof. No issues with my actual app though and they actually signed-in and used it.

Hopefully this helps someone! There is light at the end of the tunnel. Google seems faster than Apple right now, not sure why.

It's an open source app that cleans up your Android TV, turns off ads, trackers and bloat in a few taps. Side load apps your TV's store doesn't carry, send files from your phone, and see which apps use data and where they connect.

It's all Kotlin, UI in Jetpack Compose with Material 3 Expressive. A few bits devs might find useful:

- a remote with no lag: the usual `input keyevent` starts a new process for every key press, which is slow. Tellyscope starts one small helper on the TV and keeps it running, so key presses land instantly

- real app names and icons: ADB normally only gives you package names, so a second small helper reads them on the TV and is removed right after

- the ADB client runs entirely on the phone (pure Kotlin on Kadb), including Android 11+ wireless pairing and mDNS discovery. Every reopen of the TV's pairing dialog picks a new port, so it browses mDNS fresh each time instead of trusting the last one

- under 3 MB: most of the crypto library Kadb depends on gets trimmed, keeping only the handful of pieces it actually uses. That alone saved ~700 KB

Happy to answer questions on any of it. It's Free, GPL-3.0, no ads, no tracking, no account. It makes two internet requests: the cleanyourtv debloat lists from GitHub, and an update check you can turn off.

GitHub (APK + source): https://github.com/man15h/tellyscope

Disclosure: Most of the code is written by Claude Opus 5.5 + Fable 5, and I direct the work. what gets built, how it should behave, and what's safe to touch. It's not prompt and ship. Every change goes through a pull request that gets reviewed before I merge it, and CI runs the build, unit tests and lint. Risky features get e2e tests on an Android TV emulator first. The safety rules are hard coded rather than left to the AI and I've created and maintained open source projects since before the AI era. It's GPL-3.0, so you can read all of it on GitHub

I'm building an app using Supabase Auth, and my email verification emails are landing in users' spam folders.

For those who've dealt with this, what worked for you? Would only configuring SPF, DKIM, and DMARC solve the issue?

Any practical advice from developers who've fixed this would be greatly appreciated!

I'm looking to modernize my Android CI/CD setup to make it as AI-friendly and low-maintenance as possible for our company's daily workflow with coding agents.

I’m considering Dagger.io, do any guys has actually run Android builds through Dagger and how does it feel, or is there a better tool I should look into instead?

I thought setting up an Android build environment on Android itself would be pretty straightforward. 😭

My original plan was simple: get OpenJDK 25 from the Termux repositories, set up Gradle, install the Android SDK tools, and start building my IDE.

Well, that turned out to be a lot harder than expected.

Missing libraries, broken paths, directory issues, incompatible binaries, environment variables, and tools that just wouldn't cooperate. Every time I fixed one thing, something else seemed to break. I spent way more time fighting the toolchain than actually building the IDE.

My laptop is broken at the moment, so I decided to use my phone and AI tools to start working on this project instead. I have some programming experience and a basic understanding of Java, but writing and debugging code for a project like this entirely on a phone is a challenge of its own.

Honestly, I started this mostly out of boredom and curiosity. I wasn't expecting it to turn into such a deep rabbit hole.

After roughly two days of tinkering, debugging, and trying to get everything working together, I finally managed to build my first simple test APK!

That was a pretty satisfying moment. Although, naturally, I later discovered that the SDK manager I'd been working with was deprecated. 💀

For now, it's just a basic Android IDE, and there's still a long way to go. But at least I've got something working, and that's a start.

I'm curious: has anyone here tried setting up a complete Android build toolchain directly on an Android device, especially outside a traditional Linux desktop environment?

What were the biggest compatibility issues you ran into? And are there any tools or approaches you'd recommend for making this setup less painful?

I'd love to hear about your experiences!

I'm an Android dev (Kotlin + React Native) trying to get models genuinely running on the Hexagon NPU of my iQOO Neo 10R (Snapdragon 8s Gen 3, SM8635, HTP V73, 4 MB VTCM), not on the CPU or GPU fallback.

What I've learned so far: - Qualcomm's ladder is FP16 → W16A16 → W8A16, with AIMET (AdaRound, SeqMSE, QAT) for accuracy recovery - The ORT QNN EP rejects dynamic shapes and Loop/If, and disable_cpu_ep_fallback=1 is a cheap check that everything stayed on the NPU - Most tutorials target V75 (8 Gen 3), and those binaries won't run on V73 - Apps need <uses-native-library android:name="libcdsprpc.so"> and extracted native libs (useLegacyPackaging) for the skel to load

Questions for anyone who has shipped this: 1. If you fine-tuned (LoRA or full) a small LLM or vision model, did you do QAT, or PTQ after fine-tuning? How much accuracy did W8A16 or W4A16 cost you? 2. What changes to the architecture did you have to make to stay fully on HTP (op swaps, static KV-cache layout, splitting the model into parts)? 3. Has anyone got a QNN context binary running from a normal third-party app on vivo/iQOO or Xiaomi firmware? Same-chip Poco F6 logs show llama.cpp's Hexagon backend failing with 0x80000406.

Happy to share my notes and code back. Thanks!

There is now a new way to run a Linux distribution on Android using UMLinux. UML is a program that executes an independent Linux kernel as if it were a standard user-space process within a Linux system. This allows for running a distribution that supports system init, Docker, and various other features that do not function in proot-distro. Notably, it operates without requiring root access or AVF, is faster than QEMU in TCG mode, and utilizes ptrace or seccomp. To provide internet connectivity within the distribution, additional programs such as slirp4netns, passt, or gvproxy

An open-source Android library for the iconic Matrix digital rain effect, rendered natively on Canvas — not GIFs, Lottie, or video backgrounds.

⚡ Customizable rain, touch interactions, shockwaves, glitch effects, transparent overlays, and Android View + Jetpack Compose support.

Built to be integrated into real apps, not just copied from demo snippets. Still evolving!

🔗 https://github.com/boy-offi9-inc/matrix-rain-view

What would you build with it?

I've about 2+ years of experience in Android dev and been doing DSA in c++ in college(current organization did not have any DSA rounds). I'm planning to switch in the coming months. So should I do relearn DSA in Kotlin or C++ would be fine?

Thanks.

Hi

I'm building an Android app and trying to implement an overlay that stays attached to a specific product page, but I'm struggling to get the behaviour right.

For example, imagine browsing a product on Amazon. I want the overlay to behave like this:

• On the product page: The overlay should appear and stay associated with that specific product page.
• When scrolling away: The overlay should disappear immediately when I leave the product page, rather than remaining fixed on the screen.
• When scrolling back: If I return to the product page, the overlay should appear again.
• Smooth transitions: There shouldn't be any delay or flickering when the overlay appears or disappears.
• i need help with flutter tvh

Currently, the overlay either stays fixed on the screen while I scroll through other pages or takes too long to disappear. do i need to learn about flutter ?

I'm looking for a solution that makes the overlay behave as if it's attached to the product page itself, rather than floating independently over the entire app.

Has anyone implemented something similar on Android using an accessibility service, a floating window, or another approach? I'd really appreciate any suggestions, technical guidance, or examples!

Thanks in advance!

My Vestel TV has 900 MB of RAM and the stock launcher was slow and full of ads, so I built OMNI: a launcher in plain Java (0.7 MB), a Control Center on INFO, a typed/voice assistant, device notices, and Kotlin apps (Cinema, Weather…). There's also a small Python server that turns a folder of films into a library with posters and resume. Free, Apache-2.0, no ads or tracking (the README lists every outside host). Tested on three TVs , so more reports from other TVs are very welcome. I verified it on real hardware. [RELEASE ON V.1 IS YET TO COME IN THE FOLLOWING HOURS]

Github(https://github.com/Rashica07/omni-tv)

Hi all,

As a hobby I'm building a personal voice assistant for my phone (Kotlin / Jetpack Compose), powered by the Claude API: calls, SMS, Gmail, calendar, Spotify & Sonos, Home Assistant (lights, alarm, TVs, energy usage…).

Code is public: github.com/NicoPi-dev/Assistant

Everything works well except the wake word, which bothers me.

**Current setup**

- A foreground service (microphone type) listening continuously with **Vosk**, offline, using a restricted grammar ("hey claude" + [unk]) and a confidence threshold.

- It works, but the mic is open 24/7: Android's green privacy dot stays on, it drains battery, and I'm not thrilled about it privacy-wise, even though everything stays local.

**What I'm after**

Something closer to "Hey Google" / Gemini: very low-power listening, ideally hardware (DSP) based, that only wakes the app on the hotword.

**Constraints**

- Free, no subscription or time-limited key

- Offline if possible

- No root (OnePlus 10T, OxygenOS 15 / Android 15, locked bootloader)

- Reliable: few false triggers (TV, conversations)

**Already looked at**

- **Picovoice Porcupine**: excellent, but the free tier is limited and needs an account key.

- **openWakeWord / microWakeWord**: promising, but unsure about battery impact running continuously on Android.

- **VoiceInteractionService / HotwordDetectionService**: the official DSP route, but it seems restricted to system/privileged apps (CAPTURE_AUDIO_HOTWORD).

- Setting my app as the **default assistant**: works for long-pressing the button, not for voice.

**Questions**

1. Can a third-party app set as default assistant access the hardware hotword on a non-rooted device? Has anyone pulled it off?

2. Otherwise, what's the most battery-friendly software approach you know: a tflite model like microWakeWord, VAD gating before Vosk, listening only when the screen is on or in the car…?

3. Tricks to limit listening automatically: while charging, when connected to Android Auto, at home on Wi-Fi…?

Any pointers or experience welcome. Thanks! 🙏

Hey Android devs,

Over the past few weeks, I’ve been working on an open-source framework and native runtime (Kotlin + C++17 NDK) designed to detect on-device hardware acceleration (Snapdragon NPU, Adreno GPU, Hexagon DSP, and ARM Cortex CPU) and route models to their optimal backend.

It features an embedded llama.cpp runtime for GGUF reasoning models alongside TensorFlow Lite (NNAPI/GPU delegates) and ONNX Runtime.

I wanted to share the benchmarks, lessons learned debugging the NDK/JNI bridge on real silicon, and how we solved common Android OS memory and storage constraints.

Real Silicon Benchmarks (Samsung Galaxy S22 - Snapdragon 8 Gen 1, Android 14)

Tested with Qwen3.5-2B Reasoning (Q4_K_M, ~1.2 GB):

Key Architectural Decisions & Android Gotchas

1. Zero JVM Heap Overhead (Preventing LMK Kills)

One of the biggest risks running LLMs on Android is the Low Memory Killer (LMK). We bypass the JVM heap entirely: models are memory-mapped via native mmap() syscalls directly from context.filesDir into C++ space. The JVM heap stays below 60 MB even during heavy generation loops.

2. ARMv8.4-a / ARMv9 Vector Flags in CMake

In CMakeLists.txt, passing -march=armv8.4-a+dotprod+i8mm -O3 enables Clang to generate vector instructions (SDOT/UDOT and SMMLA INT8 matrix multiply). This sustains 7.70 tokens/sec on 4 threads, handling 300+ token <think> reasoning chains smoothly.

3. Thread Affinity & Thermal Throttling

Octa-core Snapdragon SoCs typically feature a 1+3+4 topology (1 Prime Cortex-X2 + 3 Gold Cortex-A710 + 4 Silver Cortex-A510). Setting nThreads = 4 saturates the performance cores without starving Android's Main/UI thread or dumping heat into low-efficiency Silver cores. Generation stays thermally stable for 10+ continuous minutes.

4. Bypassing Android 11+ Scoped Storage via Embedded REST Server

Pushing 1GB+ GGUF files via adb push frequently hits permission or Knox SELinux issues. The app embeds a lightweight NanoHTTPD server on port 8080, enabling model uploads and inference directly over local Wi-Fi:

# Upload model directly into the app sandbox
curl -X POST http://<PHONE_IP>:8080/api/v1/models/upload \
  -F "file=@./models/Qwen3.5-2B.Q4_K_M.gguf" \
  -F "name=Qwen3.5-2B.Q4_K_M.gguf"

# Query the phone from any machine on LAN
curl -X POST http://<PHONE_IP>:8080/api/v1/llm/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen3.5-2B.Q4_K_M.gguf",
    "prompt": "<|im_start|>user\nExplain Android memory management in 30 words.<|im_end|>\n<|im_start|>assistant\n",
    "max_tokens": 100
  }'

Source Code & GitHub

The project is 100% open-source under the MIT license:
GitHub: https://github.com/rafael-b-souza/ai-hardware-detector

Would love to hear thoughts, feedback, or PRs from other Android engineers working on NDK, on-device ML, and edge inference!

There is not a guarantee that a given USB-C-to-C cable supports PD, see the article USB-C was a missed opportunity and it’s too late to fix the mess.

Does Android have any API that lets an application check whether USB PD is currently active?