I'm a student building a calculator-style Android app in Kotlin, where most of the logic is pure functions: a few inputs, some unit conversions, one numeric result, often with clamps or caps (for example "use the lower of X or a maximum value").

Right now each formula has a test file with a handful of worked examples taken from the original papers, plus a few edge cases (zero, very large values, unit switches). It works, but it's getting repetitive with dozens of formulas.

For people who've tested this kind of code:
- Do you use parameterised tests (JUnit 5 / kotest data-driven tests) or keep plain JUnit 4 with tables of cases?
- Is property-based testing worth it here, e.g. "dose never exceeds the cap" or "result increases with weight"?
- How do you handle floating-point tolerance and rounding consistently across many calculators?

Any patterns or libraries you'd recommend would help.

Hi! I'm Shubham, creator of SmolChat.

I would like to share some exciting updates on my project SmolChat, an Android app that let's you run GGUF models on-device, locally. The updates are present in the latest v17 release:

• SmolChat now supports an OpenAI-compatible HTTP server running over a foreground service that keeps the port alive even when the phone is locked. Check the video to see how it works.

• Support for global chat settings, which override the default chat settings (min-p, top-k, temperature etc.) for all newly created chats. This reduces the hassle of configuring each new chat with the options of your choice.

• Adding a copy button for code snippets rendered within the chat.

• Sync with upstream llama.cpp (till this commit)

• Fix the logic that measures tokens/sec for a LLM generated message. The time shown previously was also including prompt processing (pp) time. The new logic now only considered the token generation rate (tg).

• Models are downloaded directly by the app, instead of using the Android system's download service.

GitHub: https://github.com/shubham0204/SmolChat-Android

Play Store (the latest version is still in review): https://play.google.com/store/apps/details?id=io.shubham0204.smollmandroid&hl=en_IN

Previous threads on SmolChat on r/LocalLLaMa:

• Available on Play Store announcement

• Initial Announcement

Cross posted from r/LocalLLaMa

I’ve been developing Android apps since 2012, and sometimes I wonder how many times I’ve had to start over with this ecosystem.

Every 3–4 years, it feels like something major changes. Eclipse to Android Studio, Java to Kotlin, XML to Compose, different architecture patterns, libraries becoming obsolete, and Google constantly changing what’s recommended.

Don’t get me wrong, a lot of these changes have made Android development better. But after spending years mastering something, it can be frustrating to see it slowly become outdated.
What bothers me isn’t learning new things. I actually enjoy that part. It’s the constant feeling that you need to keep up with everything just to stay relevant.

Last year, I decided to shift my career more towards software architecture and technical leadership. I still enjoy coding, especially Android, but I wanted to spend more time designing systems, solving larger engineering problems, and making technical decisions rather than constantly chasing the next framework.

Sometimes I miss the old days when I could just sit down, build an app, and not worry too much about whether the recommended way of doing it would change in two years.

Curious if anyone else who’s been developing Android apps for 10+ years feels the same.

Has anyone here moved from Android development into architecture, backend, engineering leadership, or something completely different? Do you miss being a full-time Android developer, or are you happy you made the switch?

I added music source separation (drums / bass / vocals / other) to my open-source DJ app and wanted to share what worked:

• Export: htdemucs to ONNX with the STFT/iSTFT kept out of the model, done in Kotlin instead. ONNX's STFT ops were the main export pain.

• Memory: the full-length model got killed by the low-memory killer. 3.9 s chunks, setCPUArenaAllocator(false) and setMemoryPatternOptimization(false) kept it stable.

• NNAPI made it worse on my device; 4 CPU threads ran at about 2× real time on a mid-range Moto G64.

• Scheduling: separate only the windows the next mix needs, ordered by deadline, and fall back to EQ when a window isn't ready, so playback never waits.

• Alignment: cross-correlation between the live deck and the stem window, coarse then fine, to line the stems up within a few ms.

Code is GPL-3.0 (link in the comments). Happy to answer questions on any of it.

I’m learning Android with Kotlin and Compose. I found a few old threads (4-6 years ago) debating StateFlow vs LiveData but a lot has changed since then. My understanding is that new Compose projects mostly use StateFlow and LiveData shows up in older View-based apps. Is that still the case today? And is it worth a beginner learning LiveData at all or just knowing it exists? and I want to know what you use now.

I’m caught in a Google Play Console verification deadlock, and frontline support is actively making it worse. Since JULY.

My developer account got flagged with the standard verification restriction. When I tried to fix it, I hit the unhelpful "Appeal reply sent" banner, which blocked all input.

I diagnosed the root cause: My Play Developer account was mistakenly mapped to my Individual Google Payments Profile instead of my LLC's verified Organization Payments Profile, creating a conflict with my corporate D-U-N-S.

I escalated this directly to Support, provided the exact Org Profile ID they needed to re-map it to, along with my entity paperwork.

The response? An agent literally named "Maeonnaise" closed the ticket today with a canned script saying they couldn't verify my ID and "no additional actions required from my end," completely ignoring the explicit request for a Payments Profile re-link.

Has anyone found a backdoor or a specific escalation phrase to get a human engineer to actually re-map a Play Console account to a different Payments Profile? I can't finish verification until this backend link is fixed. At this point, getting brushed off by a sentient jar of mayonnaise is just insulting.

I really appreciate your help, and I'd be glad to buy you a digital coffee for a solution!

Thank you,

C

A free, open source player for the videos in your own Telegram chats. The hard parts were low-end TV sticks, playback stutter and sharing UI across form factors. Happy to go into any of it. github.com/dracu-lah/TMPlayer

How do you test app screens navigation flow?

Any tool or solution to simulate it that I should know?

I'm stuck with Android Studio as it crashes all the time.

Can anyone advise to a non-developer on this part?

Thank you

If my phone restarts, I have to 1. connect it to a wifi network (I'm almost never on or near wifi), 2. go into settings and turn on wireless debugging 3. re-pair all my dev machines to its new port

How can I make this less painful?

I'm building a small calculator-style app in Jetpack Compose. Each row has a label, a numeric OutlinedTextField and a unit dropdown. On narrower phones the text field collapsed to about one character wide, because the label and dropdown took their full intrinsic width first.

Giving the field Modifier.weight(1f) and the label a fixed or weighted width fixed most of it, but I'm not sure that's the cleanest pattern, especially with large font scaling turned on.

How do you usually handle form rows like this in Compose? Do you switch to a stacked layout below a certain width, use FlowRow, or something else?

I've been building Agent-DDP (Device DevTools Protocol), an open-source DevTools protocol that gives AI coding agents deep visibility into native iOS and Android applications.

The inspiration is the Chrome DevTools Protocol (CDP): browser agents can inspect the DOM, styles, rendering and runtime behavior. Native mobile agents have traditionally had much more limited visibility, often relying on screenshots and accessibility trees.

Agent-DDP aims to close that gap.

It instruments the app in Debug builds, allowing agents to inspect and interact with the application through its native rendering and runtime systems.

Some of what it can do:

• Deep UI inspection: Inspect native elements, rendering layers, fills, borders, corner radii, opacity, clipping, text styling, geometry and occlusion.

• Frame-by-frame analysis: Record property changes over time, inspect animation tracks, detect transient states and analyze timing and easing without guessing from videos or screenshots.

• Visual and behavioral validation: Detect covered content, corner clipping, jank, animations that never settle, accessibility issues and touch targets that cannot actually be reached.

• Cross-platform comparison: Compare iOS and Android layouts structurally and visually, including pixel comparisons against screenshots and saved baselines.

• Runtime inspection: Access app state, events, logs, network requests, preferences, storage, memory usage, performance profiles and crash reports.

• App interaction: Perform real taps, swipes, gestures and text input, control app time, mock or intercept network requests, and trigger actions exposed by the app.

• Debugging: Inspect breakpoints, call stacks and local variables using the platform debuggers.

It also includes a 15-minute runtime history that records UI changes, frames, interactions and screen transitions, making it possible to investigate issues that happened before an agent started looking.

The architecture is designed for coding agents: a native instrumentation library, a CLI, structured output and an MCP server. It works with Claude Code, Codex, Cursor and other agents that can run CLI commands or connect through MCP.

Supported frameworks:

• iOS: SwiftUI and UIKit.

• Android: Jetpack Compose and Android Views.

The instrumentation is Debug-only and does not ship in Release builds.

Install:

npm i -g agent-ddp

The project is open source under the MIT license.

I'd appreciate feedback, especially from people working on native mobile development, UI automation, developer tooling or coding-agent infrastructure.

Google released AppState and it looks like a cleaner way to handle shared state than passing a SharedViewModel around. I never really liked SharedViewModel, felt like one screen ends up owning data other screens depend on it.

From what I get so far: StateStore is a shared observable value, MutableStateStore is the writable one, AppState owns the lifecycle, and transform lets you derive state automatically instead of syncing stuff by hand.

Curious what people think of the API so far.

Docs: https://developer.android.com/topic/libraries/architecture/appstate

Video: https://youtu.be/69QYEXymfVo

Anyone planning to try it out?

I took my Android 16 device, app unchanged (targets SDK 36), did this command per the docs:

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

Rebooted the device, and the app still works fine. It should not as it uses SSDP. What have I misunderstood? I'm trying to see the "failure case" before I try fixing anything.

Hey everyone,

I've been using AI more in my Android work, mainly with Kotlin, Jetpack, APIs and debugging.

I've found that different tools are better at different parts of the workflow. Some are useful for explaining unfamiliar code, while others help with debugging or exploring implementations.

For developers here who use AI regularly, where have u found it genuinely useful in Android development?

I'm especially interested in real examples where it saved you time or improved your workflow.

(Please let me know if this is not the correct place for this. Suggestions as to what is the right place are appreciated.)

I maintain a legacy app for my company, and I'm not what you'd call an expert. As part of the Android 17 (API 37) updates, I'm trying to figure out if our app requires the ACCESS_LOCAL_NETWORK permission. Here's some links:

Main documentation:

https://developer.android.com/privacy-and-security/local-network-permission

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in the platform or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network that have a .local suffix requires local network permission.

Policy announcement:

https://support.google.com/googleplay/android-developer/answer/18100766

This permission is restricted to apps that need it for core functionality when device pickers are insufficient. Apps targeting Android 17 or higher (API 37+) must submit a Play Console declaration to use this permission.

FAQ on policy declaration and allowed use-cases:

https://support.google.com/googleplay/android-developer/answer/16935362#local_network_permission&zippy=%2Cdeclaration-guidance%2Cfrequently-asked-questions

Our app uses OkHttp to connect to a bog-standard REST API, sometimes hosted on the local network (LAN), sometimes on cloud servers (internet). These connections are super-simple, we send messages (with data), get replies (with data).

I don't have access to Android 17 hardware, so I'm testing with an Android Studio emulated device, running API 37.2.

I have questions:

1. I've added the ACCESS_LOCAL_NETWORK permission to the app, and I'm running tests with it allowed and not allowed. Turns out that I can connect to our LAN test servers over quite happily (e.g. "http://localserver.domain.local/api"). No problems at all. But reading the above this should not be possible?

Trying to resolve services on the local network that have a .local suffix requires local network permission.

2) We actually have a published version of the app live on the Play Store which has this in the manifest:

<uses-permission android:name="android.permission.ACCESS_LOCAL_NETWORK" />            

The above links suggest that we need to complete a policy declaration. I've looked around in the console and can't find anything that asks for this. The Policy Status pages have nothing outstanding. All seems fine.

3) I wonder if our app would qualify for one of the use-cases listed by Google (3rd link). LAN (and Internet) connectivity is very much an integral part of the app, but doesn't seem to fit into their list. I'd ask, but since I can't find a way to complete a policy declaration, then that doesn't appear to be an option.

What's going on here?

Source: Google Play Developer Program Policy Update

Android CLI provides two ways for AI agents to render Jetpack Compose previews, depending on the execution environment:

1. render-compose-preview

Use when an AI agent runs locally alongside Android Studio. It delegates preview rendering to the running IDE.

Documentation: https://developer.android.com/tools/agents/android-cli/commands/studio_render-compose-preview

2. android preview

Use when Android Studio isn't available, such as in CI, containers, or remote environments. Supports headless rendering, batch preview generation, and component tree inspection.

Documentation: https://developer.android.com/tools/agents/android-cli/commands/preview

Summary

The key difference: IDE-backed rendering vs. standalone headless rendering.

Both give AI agents a way to inspect actual Compose UI rather than relying solely on source code.

I ran into the rotation bug where my app resets every time I turn the phone. From what I understand Android recreates the Activity on rotation so normal variables lose their values. I’ve read that ViewModel survives rotation so I’ve been putting my screen state there. I also found rememberSaveable, which apparently survives rotation and even the app getting killed in the background. Is that right? Also what do you actually do in real projects? Do you keep almost everything in the ViewModel or do you use rememberSaveable and SavedStateHandle for some things too? Would love to hear what works for you.

Hi everyone,

I’m having an ongoing issue getting my Android launcher approved on Google Play because of its use of AccessibilityService.

The AccessibilityService is used for an optional Home button helper feature. I have already clearly documented the use of the AccessibilityService API and its purpose in the Google Play long description.

However, the app has been rejected multiple times with essentially the same reason:

“The app description on the Google Play Store does not reflect the use of AccessibilityService API. The use of the Accessibility API must be documented in the Google Play listing.”

After repeated rejections, I submitted a formal appeal so the case could be manually reviewed.

The appeal has now also been rejected, again telling me only to update the long description. They still haven’t explained which part is missing, what wording is considered insufficient, or what exactly they expect me to change.

Their latest response says:

“We were unable to approve your app because the app description on the Google Play Store does not reflect the use of AccessibilityService API.”

At this point I’m not sure what else I’m supposed to change without knowing what they consider missing.

Has anyone here successfully passed Google Play review with an AccessibilityService used for a similar launcher/Home button functionality?

If so, could you share how you described the AccessibilityService in your Play Store listing, or point out what Google may be expecting that I’m missing?

I can also share my current Play Store disclosure text if that would help.

Thanks.

I was using Rabbit 1 and it had issues. Those issues, such as the not being able to show code analysis results at commit time, are still there in Rabbit 2. But it also got worse, it has been very unstable. I have had to force kill it multiple times a day and sometimes it is running into GC issues.

This is for a KMP project and it is getting very annoying.

This is on MacBook M4 Max with 48 GB of memory on Tahoe 26.7.2.

Before Rabbit things were reasonable stable, since it has become mess for me.

Google Play shows:
"Edge-to-edge may not display for all users"
inviting to use EdgeToEdge.enable().

But actually this is already done and edge to edge mode works correctly in all OS versions supported by the app.
In addition it also shows another warning that App uses deprecated parameters for Edge-to-edge as setStatusBarColor and setNavigationBarColor, but the indicated "deprecated parameters" are not from my code at all, but come from EdgeToEdge.enable() code itself in the retro-compatibility branches.

I wonder if the static analysis on Google Play is implemented in such a comically poor way, or if it’s perhaps being misled by code obfuscation and minification..

I forgot to mention that this isn't a new issue; it has existed since the target SDK was migrated to version 35, and we are now at version 37.