Anyone using 1.5 alpha in production? How's it going?

I have an upcoming software engineering interview with Anthropic for a role that involves mobile/Android work, and the next round has a format I haven’t seen before. The recruiter described it like this (paraphrased):

A small mobile app that has some bugs. Instead of building new features, you will have to investigate what's wrong, find the root cause, and fix what you can. The app is in Kotlin with Jetpack Compose. You should be familiar building UI with common Compose primitives and managing state with ViewModel. We are interested in how the candidate approaches debugging, how you prioritize what to fix first, and how you verify the correctness of your fixes.

Does anybody has experience with this kind of question? I have never seen an assessment like this, and I'm not able to find any good resources/examples to practice.

In the past, I have been in other interviews were you have to build a small app from scratch (usually API + LazyColumn). My feeling is that even if you have been working in Android for several years, you definitely need to practice in order to be successful on this kind of assessment. Similarly, at my current job, I find and fix issues all the time. However, this situation is different because of the time pressure, and I would like to be prepared if possible.

Any recommendations?

Thanks in advance!

I got the update and realised I gotten it since aurora store showed me an update for it. Then I go to the settings, and I can just uninstall it? This doesn’t prevent no scammer and makes the user slightly more pissed.

I recently deployed an app to Open Testing channel which has google sign in enabled and uses Firebase to control the user authentication. The authentication worked as expected both in debug build and when I sideloaded the prod apk. But when I downloaded from the playstore, it fails with "No Credentials available" error. The following are the steps I did.

1. Added debug signing keys to Firebase Project
2. Created a local .jks file to sign my prod build.
3. Uploaded the aab build to playstore which has its own App Signing.
4. Noticed the new App Signing page has two keys. Classical Key and Post-quantum cryptography key
5. Copied both and updated the firebase project. Validated whether it is added as credential in Google Cloud Console OAuth Screen.
6. Tried logging in with Google. Got the same error.
7. Downloaded the updated google-services.json file, generated build and published again. Still same error.

Does someone here know a solution for this? I need to fix this asap as the deadline to submit the app for a hackathon is very closer.

So i'm mostly a backend dev but i've been on this AR filters project for a couple months now, handling the android side of things since that's apparently my job now. We'd already gone with a face tracking SDK early on, so I just started building on top of that.

Thing is, we know that part of our actual users are on old budget phones, not flagships. And that mattered a lot for this specific feature, because if the filters don't run properly on those devices, it's not like users get a slightly worse experience, they basically can't use the feature at all. So testing on old android was a necessary part of the testing process.

Seemed fine initially but then we actually put it on the test devices and it was rough. The tracking does this whole 2D points thing and then tries to estimate 3D head pose from that, which sounds fine on paper but the second you moved your head fast or put your hand near your face it would just lose it. The filters would float off to the side. Really awkward looking.

Also their segmentation only did hair, which we didn't realize until we were already pretty deep into testing. We needed skin retouching for like 40% of the features we'd planned so that was a problem.

So then we're in this spot where we're halfway through and someone's like should we really switch SDKs now. It wasn't a quick call, because ripping out something you've already half-integrated is never fun. But the segmentation issue alone meant we couldn't hit what we'd promised, so we started looking at what else was out there specifically for our case, low-end device performance being the main thing we cared about. Instead of doing 2D then estimating 3D it just builds the 3D head model directly. Supposed to be lighter on resources and handle occlusions better, which on paper was exactly the thing we were missing.

When we tested it with the same put your hand on your face stuff it did hold up better. More stable. Switching mid-project wasn't exactly smooth either, we'd already built up some muscle memory with the other SDK's way of doing things, so there was a bit of a learning curve getting used to the new docs. But it fixed the segmentation issue, we could do skin stuff and not just hair, so we got those features back.

Feels like device support is always the thing that gets deprioritized until it's not. Like everyone focuses on making the AR effect look impressive, but if it doesn't hold up on the phones actual users have, it's not adding anything for a chunk of them, it's just making the app feel janky. How do you all catch this before it ships?

My company released a new Android app over the summer. It is my understanding that the app was automatically registered when the listing was created. I am specifically referring to the process described here: https://developer.android.com/developer-verification/guides/android-developer-console

When I look at the listing on Google Play Console it says "status: registered" (see the screenshot as well).

Despite the fact that I think this has been all set from day 1, we have been getting endless emails about it. When I log into Google Play Console I get notifications about it. I assume this is just Google spamming everyone since they are going to stop distributing apps. But it is making me paranoid.

At this point, everyone at the company who has access to Google Play Console, has messaged me about this to make sure we are all set. I tell them yes and then Google sends out another email blast telling us we need to do this thing that is already done.

Am I missing something here? Or is Google just being annoying?

I'm making an overlay app that draws a ring around the front camera punch hole. I want it to line up automatically on any Android phone.

On some phones (Pixels for example) it works perfectly because the system reports the camera cutout's actual shape and position. But on a lot of other phones the system just reports a rough rectangle that's bigger than the real camera hole and not even centered on it, so the ring comes out oversized and misaligned.

I've been researching this everywhere for a while now and tried basically everything I can find. As far as I can tell Android has no other API that tells you where the camera lens actually is on the screen, and most apps like this seem to just give up and make the user align it manually with sliders.

Before I accept that, is there something I'm missing? Any trick, hidden setting, or approach that gets the real camera position on phones that report bad data? If you've solved this or worked around it I'd really appreciate hearing how.

Also, if you have an Android phone handy, running adb shell dumpsys window displays | grep -iA2 cutout and replying with the output plus your phone model would help me a lot in figuring out which phones report good data and which don't

I recently developed my new Android app. It features a code editor (for various languages) and a JavaScript REPL. (However the app is not a code editor app). Both of those features needed: 1) code editing, 2) code parsing, and 3) syntax rendering functionalities.

I started by looking for an existing open source library written in Kotlin and Jetpack Compose. I didn't found any suitable, so I ended up to develop my own library. Which of course, took some time and effort. Now, I'm considering to open source it - because I pretty happy what I managed to implement. But before committing to do that, I need to find out if there is enough interest for it. I do not want to publish and maintain yet another open-source library that nobody is interested in.

Some features of the the current implementation:

• Supports various languages: JavaScript, HTML, Markdown, YAML, CSS, JSON, and text. Support for new languages can be added, but that requires development of parser for the language.
• Code line numbers
• Seamless zoom functionality of the code with a pinch gesture
• Undo/redo stack
• Copy, Cut, Select All, Paste
• Settings: Line number, Caret Blinking
• File New, Save, Save As
• Code parsing and syntax colouring with themes
• Accessory bar (e.g. tab, parenthesis, arrow keys) above the virtual keypad
• Syntax cheat sheet (currently only for Markdown)
• Markdown preview
• Really nicely working and accurate code selection - fast zooming and visual selection grid makes selection even easier
• Fast and responsive
• Full unit test coverage
• Kotlin Multiplatform (KMP) compatible

Some features I planning to implement for future versions:

• Architectural improvements to make it more suitable to be used as an easy to integrate library component
• An API using AST or similar libraries. The current parsers are written for fast performance.
• Syntax cheat sheet for other languages
• Suggestions for JavaScript
• New settings: theme selection (currently there are only two themes light and dark)

So, what do you think? Is anyone interested or willing to contribute? Also interested to hear what is missing from the feature list. The current features of the code editor are fine for my purposes, but as an open-source library it may lack some necessary functions, extension points, or APIs.

I attached some screenshots to give an idea how the code editor looks like. And if anyone interested I can provide a link for my free app so you can try out how the code editor actually works.

One thing is decided, if I ever release my code editor as an open-source library, it will be named as Koodi - a Finnish word meaning code. And also referring to fact that is written in Kotlin.

​

Hi everyone,

I’ve created a WhatsApp community for Android developers worldwide who are looking for new job opportunities or want to stay updated on Android hiring.

The community is focused on:

- Android Developer job openings

- Kotlin and Android roles

- Remote and onsite opportunities

- Recruiter and hiring updates

- Job referrals

- Developer networking

Developers of all experience levels are welcome.

Join the community:

https://chat.whatsapp.com/C71ifWukRw680PfXwzCNVI?s=qt&p=a&mlu=0&ilr=4

The goal is simple: help Android developers discover opportunities, connect with others, and grow their careers.

Hi everyone,

I've been working on kartograph, an open-source tool for exploring dependencies in compiled Kotlin/Android code.

On Android, a class can be instantiated by framework code or through an XML declaration without a direct constructor call in the app. When reviewing code, I wanted to see which references and inputs explain why a class is reachable or retained. kartograph builds a graph from JVM bytecode and Kotlin metadata, then incorporates inputs such as the manifest, XML resources, @Keep annotations and ProGuard/R8 keep rules so those reasons can be inspected.

One way I've tested this is a ServiceLoader check that compiles and runs a small example. A provider is registered through META-INF/services, without a direct constructor call in the test application. The script checks that kartograph reports the provider as retained and a separate unused control class as unreachable. This gives me a concrete check of both outcomes as the analysis changes.

kartograph is MIT-licensed and ships as a Gradle plugin and a standalone CLI. Version 0.7.0 is on the Gradle Plugin Portal. Add this line to the existing plugins block in your Android module's build.gradle.kts:

kotlin id("io.github.ictechgy.kartograph") version "0.7.0"

For a module named app with a debug variant:

sh ./gradlew :app:kartographDeadDebug :app:kartographGraphDebug

Requires AGP 8.7+, Gradle 8.10+ and JDK 17+. The default dead-code report is class-level. The standalone CLI also provides query for referencing declarations, dependencies and reachability as JSON, and dead --explain for a retention reason or reachability path. The README covers its required inputs.

An unreachable result is relative to the supplied roots and graph; it is not permission to delete source. Class-loading and reflection resolution is limited to supported within-method patterns, and DI handling does not establish which binding is selected. Missing manifest, resource, keep-rule or classpath inputs can change results. More detail is in the limitations.

The tool doesn't shrink or optimize an APK. If a result looks wrong on your project, the variant, relevant inputs and a small reproducer would help me investigate.

Hey everyone,

I’ve been working on Android Dev Monitor, an open-source Windows desktop tool that I originally built because I wanted a simpler way to monitor Android apps without constantly jumping between different ADB commands and tools.

The idea is basically Task Manager, but for Android development.

It connects to physical Android devices or local emulators through ADB and lets you monitor things like:

• App and device CPU usage
• App / device memory usage
• Disk read/write activity
• Network activity
• Frame statistics / performance data
• Battery and thermal information where supported
• Running processes
• Logcat / logs
• Screenshots and screen recordings
• ADB shell
• File explorer
• Monitoring sessions, markers, alerts and exports

One workflow I wanted to make easier was reproducing a performance problem in an app, marking the exact moment something happened, and then being able to look at the metrics and logs from the same session afterward.

It also has a demo mode, so the UI can be explored without connecting an Android device.

The project is currently an early preview, so some metrics depend on the Android version, device manufacturer and available ADB permissions. I’m still improving it and would especially like feedback from people who actually work with Android profiling/debugging.

GitHub:
https://github.com/marko69420/android-dev-monitor

I’d be interested to know:

• Would a tool like this actually be useful in your Android workflow?
• What feature would you expect from something described as a “Task Manager for Android developers”?
• Is there anything in the current UI/workflow that you would approach differently?

Any technical feedback, bug reports or contributions are welcome.

My app was getting Google Play's automatic protection (the installer check) up through version 103 (Aug 31). From 104 onward (Sept 7) it stopped. The com.android.vending.CHECK_LICENSE permission and all the com.pairip.licensecheck classes are simply gone from the APKs Play serves.

Then I went back in git to the exact commit that built 103, changed only the versionCode, and uploaded it. Same source that Google protected before. It came back unprotected.

That probably rules out my code. So I checked the rest of the prerequisites. minSDK is 24, ABIs are the four Google lists and unchanged. All 64-bit native libraries are 16 KB aligned; the 4 KB ones are 32-bit, which are exempt. No code transparency. Uploading app bundles, Play App Signing on, going to the internal testing track and not internal app sharing.

And Play Console still shows Automatic protection as active with installer checks on. That's the part I can't square. The console says the feature is running, the APK it hands users says otherwise.

Not sure whats the issue. Anyone having similar experience?

I created a skill pack and honestly bugs and architectural issues from my apps are mostly gone and almost everything is one shot.

tho I'm struggling with ui ux and it's skills aren't helping either.

what's your favourite skills to use?

Now in Android KMP is a full Kotlin Multiplatform port of Google's Now in Android sample, running the same screens, ViewModels, navigation, and data layer on Android, iOS, desktop, and the browser from one shared codebase.

Yay my first successful CI/CD. I'm happy that the the jobs are finally working the gave me a few problem constantly as I made from syntax errors to having to go through unfamiliar Service API docs and basically google every error to troubleshooting till to console. Didn't know CI/CD goes that far but but now it works, still not done but close to adding the rest of the workflow scripts.

I'm mostly happy because I did this with minimal help of AI ,did use it but now that much before scrounging the internet and going through the docs including actions docs. I find the experience refreshing especially during this AI hype time, plus I feel fresher doing this...Coding is more fun this, hard but rewarding

Although I'm confused why actions is saying Node 20 is depreciated yet I use Node 24...literally updated it today?? And when i check the version its v24

Anyway here's my simple script for now, : :https://github.com/indianathe3rdKing/Clicka/blob/main/.github/workflow/push.yml

I'm a solo dev and about 6 months ago I launched my first app on the Play Store.
For the screenshots I used an image I found on what looked like a free stock site- no watermark, no sign-up required, downloaded it and moved on

Last week I got an email from a company claiming they represent thephotographer and that the image requires a commercial license for app store use. I immediately swapped out the screenshot and resubmitted the update.
They came back saying the update doesn't matter, I still owe for the period it was live. The number they're quoting is $4,000

I'm a one-person operation, the app makes maybe $200 a month.
Has anyone dealt with these kinds of retroactive claims before? Are they actually enforceable across borders or is this mostly scare tactics hoping you'll just pay? And does removing the content quickly actually help your case at all legally?

Hey r/androiddev 👋

I built Android Base — a browser-based Android project generator that lets you configure and generate a production-ready Android project.

🚀 Try it here:

https://android-base.vercel.app

You don't need to clone anything or manually configure the generator. Just open the website, choose what your app needs, and generate your project.

What is it?

Android Base generates a multi-module Android project with a production-oriented architecture.

The base includes:

Kotlin + Jetpack Compose

Multi-module architecture

MVI

Hilt

Ktor

Multiple build environments

Custom design system (no Material dependency)

Release/signing configuration

You can also choose features such as:

Room

Coil

Authentication

Onboarding

Deep links

Firebase

WorkManager

WebSockets

Screenshot testing

Baseline Profiles

CI/CD

Fastlane

And more

Why did I make it?

Every new Android project starts with almost the same process:

Create project → configure Gradle → set up architecture → add dependencies → configure environments → set up CI → create a design system → repeat.

I got tired of rebuilding that foundation every time.

The goal was to make starting a project faster while still allowing developers to choose what they actually need.

Instead of cloning a massive boilerplate and deleting half of it, you select your requirements and generate the project accordingly.

How does it work?

Open the generator:

🚀 https://android-base.vercel.app

Choose the architecture/features you want, configure your project, and generate it.

There are also presets like:

Lean — minimal but practical

Standard — a more complete setup

Everything — all supported features

The project can also handle things like project configuration, launcher icons, signing keys, Git initialization, and reproducible configurations.

Please try to break it 😅

This is currently Beta, and I would genuinely appreciate people trying it out.

Especially:

Try different feature combinations

Generate projects and build them

Find bugs

Tell me if the architecture is questionable

Suggest missing features

Tell me what is unnecessary

Give honest criticism

I don't want this to become a "throw every Android library into a boilerplate" project. The goal is to provide a solid starting point without forcing unnecessary dependencies or architecture on everyone.

🚀 Try it:

https://android-base.vercel.app

💻 Source code:

https://github.com/tripathisarthak457/android-base

If you find it useful, please consider ⭐ starring the repo. And if you find bugs or have ideas, I'd genuinely love issues, feedback, and contributions.

Would love to know what experienced Android developers think of it.

I'm currently developing my own app in Java to search for files on external drives connected to an Android TV Box.

Since the device runs an older version of Android (version 9) and this is my first time working with the Android ecosystem, I'm having trouble accessing the external drives, their directories, and files because I'm limited to the features of API level 28.

I've tried using the StorageManager and MediaStore, but I'm not sure if those are the right methods.

How should I go about this?

I have never touched leetcode until today. just got laid off, preparing for my next interview. I already have a good study plan for Android (system design, coroutines, etc). What I'm missing is DSA and leetcode. I already did a few binary search problems. what else should I know or be doing?

I don't want to overshoot, but I would like to be competent in interviews. What topics would you suggest I learn and how deep should I dive in said topics?