I’m a senior SWE finishing a BSCS and planning to publish a small Android project as a portfolio piece. My mobile development course still teaches Android development in Java only, and when I asked about using Kotlin because the language choice is ambiguous in the description, the reactions were mixed and leaned heavily toward Java.

Since I’ve been in .NET land for years, I want to sanity‑check my assumptions with those actively working with Android today. My understanding was that Kotlin has become the de facto choice for modern Android development, especially for new projects, and hiring requirements.

For someone returning to the JVM ecosystem and aiming to use a published course project as a portfolio piece that signals current industry alignment (make HR checkboxes happy despite .NET), is starting in Java still reasonable or is Kotlin the better choice?

My long‑term goal is to move toward JVM/GraalVM‑based mobile or embedded Android work alongside any JVM‑flavored backend (I’m guessing Spring Boot or Quarkas). I’d appreciate insight on where Kotlin and Java sits in the landscape today and in the near future from this sub’s perspective.

I really miss playing BIT.TRIP BEAT. Gaijin Games stopped maintaining this after Gingerbread. I've been playing on an old Samsung Galaxy Captivate, but the experience is sub-par. What I've done is reverse engineer the old .apk made for Gingerbread into working on Android 10! It plays perfectly into the second level (That's as far as I can get right now)

I chose Android 10 because that's the highest version I have on a device. It plays great on my Galaxy S9+! I'd love to know if anyone successfully plays on newer versions of Android, please post the version and device if you do.

Known Issues:

1. This WILL NOT run on pretty much any phone released after 2021! It contains C++ code compiled for 32-bit processors and Qualcomm stopped including 32-bit cores around 2021.
2. The menu and completion screens are left aligned. This means to register a tap (especially on the "continue" between levels) you will have to tap a bit to the right and below it to activate it. The closer your phone is to a 16:9 aspect ratio, the more aligned your touches will be.
3. During the game, the text at the top and bottom is misaligned, it doesn't affect gameplay, but you can't see everything at the top all the time.

These alignment issues are very difficult to fix, no guarantees it will ever be fixed.

Download Link: https://gitlab.com/nevarDeath/bittripbeat-fixed/-/blob/main/bittripbeat_android10_patched_v1.0.2.apk?ref_type=heads

Installation Instructions:

1. Download apk here
2. Launch on device. You will get a Google Play protect Warning.
3. Tap "More Info"
4. Tap "Install Anyway"
5. Wait a few seconds
6. A dialog will appear asking for storage permissions.
7. Click "Continue" in the lower right hand corner.

VirusTotal Report: https://www.virustotal.com/gui/file/0fa0790bb6ffecf4a134342c3ab354e1145d5b8a4107a8598ef8e626b975b0e7?nocache=1
I didn't do any network traces, but I did patch out the crash logger calls to a non-existent server.

Long-time mobile/product lead here. Looking for outside perspective because I'm now questioning myself after a long argument with my boss.
Context: I work on external client apps as well as our main customer portal app — the one used by the majority of our customer base. Our mobile apps are native, built about 6 years ago:
Android: Java/Kotlin + XML
iOS: Swift + UIKit
Web: React

100K+ users. Zero limitations adding features or maintaining these apps over the years. Apps are feature rich and AI based new features are in plan for revamp.

What's happening: We have a full revamp of the apps and portal coming up, and we're updating our tech stack too. My plan:
Android → Kotlin + Compose
iOS → SwiftUI
Web → Next.js
I already have multiple Android, iOS, and web devs trained on this stack.

The conflict: My boss wants to consolidate to Flutter — one team, one codebase, covering web/Android/iOS. His argument: if I put 6 frontend devs on one Flutter codebase instead of splitting across native platforms, we ship 3x faster.

My pushback:
We have zero Flutter training on the team right now
Native apps perform better and feel more premium
We have built Flutter apps before, but only for external client projects, not our own flagship product
He thinks I'm biased toward native because it's my background. Might be some truth to that, but I don't think that's the whole story.

Anyone actually shipped a migration like this — native to Flutter, or vice versa, at similar scale? Did the "one codebase, ship faster" promise hold up? Would love real-world experience, not theory.

Hello, I have encountered this issue while developing this markdown editor.

The issue is that when i type something in the editor and do some edits, and then try to close hide the keyboard with the gesture back button git hides only the keyboard, but the app it self doesnt recognize it. The toolbar is still there and the whole editor is still shifted up like there would be still keyboard visible.

On all other devices with Android lower then 17 it works well.

I have tried to solve this issue for a long time now, I though that it might be my code issue (which it still might be), or there is something handled differently in Android 17.

If you know what might cause this error, your advice would be very helpful!

(you can see the code here: https://github.com/jotalac/git-writer )

I maintain 14 Android apps on Google Play Store, built with Codex.

The apps have approximately 5 daily users or installs, and I’m trying to decide when an app should move from active development to maintenance mode.

App count alone does not seem to reflect the real workload. I currently track daily users, but I’m unsure how to weigh support requests, crash-free sessions, release regressions, OS/device fragmentation, and release frequency.

For developers maintaining multiple apps:

- Which metrics best predict maintenance time?

- How do you set thresholds for hotfixes versus scheduled releases?

- How do you centralize crash, version, device, and support data?

- How do you keep low-traffic apps safe without spending equal time on each?

I’m interested in production experience and practical processes rather than generic tool recommendations.

I've spent hours debugging a TWA verification issue and
have ruled out all server-side causes. Looking for
insights from anyone who's hit something similar.

Setup:
- Django backend, TWA app built with Bubblewrap
- Published on Google Play (correctly installed,
latest version)
- assetlinks.json is correctly configured
(verified with Google's official Digital Asset
Links tool - "Success")
- SHA-256 fingerprint matches exactly between
Play Console and assetlinks.json
- App itself launches fine, no crashes

Symptom:
- X-Requested-With header is NEVER sent
(confirmed via server logs, 0/575+ requests
over 42 minutes)
- This means Chrome is treating the TWA as a
regular Custom Tab instead of a verified TWA

What I've ruled out:
- assetlinks.json content/history (clean, verified)
- Code logic (is_twa detection works correctly
when the header IS present)
- App signing (matches Play Console exactly)

The device in question is a budget/no-name Android
tablet (not Play Protect certified, possibly).
Has anyone confirmed that TWA verification can fail
specifically due to incomplete/non-certified Google
Play Services on certain devices? Any way to
diagnose this further without a second physical
device?

Hi guys, we have built an app and its runnig great. Now we got in touch with some customers who asked if it would be possible to have said app as a whitelable version for their businesses which would not be a problem to us, but after checking this through with AI we are now concerned as we were warned that uploading the app with a few adjustments for customers this will be marked as "Spam". BUT it also told us if we create separate accounts for each customer, it will NOT be marked as spam.

Seems a bit nonsensical to me as its still on the same platform. Anyone who has experience with that? Whats the best practice in reality? Thanks for any help!!

Hey all — I've been building a small personal app that shows step count on the Z Flip cover screen, and I've hit a wall that I think is actually a platform limitation, not something wrong with my app. Posting here because I'd love to be proven wrong, and because I suspect other cover-screen widget devs have hit the exact same thing.

The setup: My widget is a normal AppWidgetProvider/Jetpack Glance widget, registered with both the standard android.appwidget.provider metadata and the com.samsung.android.appwidget.provider metadata pointing at a <samsung-appwidget-provider display="sub_screen"> resource — which is exactly the pattern Samsung Notes uses for its own smaller cover widgets (I checked by decompiling the public Samsung Notes APK). Small minWidth/minHeight, targetCellWidth/targetCellHeight set to 2x2 and 4x2, the works.

The result: it only ever shows up as a single full 4x4 tile in the cover-screen widget picker. Never smaller.

What made me suspicious it's not my manifest: I checked Outlook and Spotify's cover-screen widgets too — both are big apps that would absolutely want a nicer cover-screen presence, and both are also stuck at 4x4-only. Meanwhile Samsung's own apps (Notes, Reminder, Weather, the phone dialer's recent-calls widget) get 2x2/4x2/tiny sizes just fine.

What I found digging into it on-device (connected via adb, compared dumpsys appwidget output for both my app and Notes, and pulled/inspected SystemUI.apk):

• The cover-screen grid is actually built on AOSP's own "Communal Hub" (Glanceable Hub) framework — the same multi-size widget grid Google built for Pixel Tablet's Hub Mode — running inside SystemUI on the cover display.
• The OS parses my widget's small size attributes correctly — dumpsys appwidget shows it registering at exactly the dp values I declared, same as Notes' widgets. So it's not a manifest/XML mistake.
• I even matched Notes' widgetCategory value bit-for-bit (both end up keyguard-only at runtime) as a live A/B test on my own device. No change — still 4x4 only.

That combination (correct registration + still forced to one size, only for non-Samsung apps) makes me think there's a package-identity allowlist gating which apps' widgets get offered at non-default sizes in the cover picker, separate from anything in the widget's own manifest.

Question for the sub: has anyone actually gotten a genuinely third-party (not Samsung-signed) widget to show up smaller than 4x4 in the native cover-screen picker, on any One UI version? I know apps like CoverWidgets and CoverScreen OS exist and can put arbitrary widgets on the cover screen — but as far as I can tell they do it by taking over the whole cover display themselves (their own widget host + presentation), not by getting Samsung's native picker to offer a smaller slot for someone else's widget. If anyone's actually cracked the native-picker case, or knows for a fact this is a partner-program/allowlist thing, I'd love to know — trying to decide whether to keep chasing this or just build my own host like those apps do.

Device/version for reference: Z Flip 6 (SM-F741B), Android 16, One UI 8.

I’m working on an Android app that needs to match users into real-time 60-second workout sessions.

I’m currently considering WebSockets for matchmaking and live session updates, with a backend handling the matching logic.

For those who have built real-time Android apps, what architecture would you recommend for handling matchmaking, connection drops, and syncing session state reliably?

I’d especially appreciate advice on patterns or libraries worth researching.

i'm struggling a bit with Figma when i want to implement the designs, i know few things but in general i'm still behind, is there any video explaining the implementation of Figma design in Compose, like cover everything: design system, typograpgy, colors, sizes, paddings, shadows, and also custom components with their own properties.

I'm developing a small Android automation app for a very specific workflow and I'm currently stuck on the audio side.

The app runs on a Samsung Galaxy Z Fold5 (of course it should work for different phones at the end of the day) and automatically calls a cinema's phone number. The cinema has an IVR/answering machine where I can navigate using DTMF tones.

The current workflow already works:

App
 ↓
Call fixed phone number
 ↓
Wait using Android post-dial ","
 ↓
Send DTMF: * → * → * → *
 ↓
Reach the cinema's voicemail menu

The next step is to automatically understand the spoken announcement, for example:

I want the app to detect the number of new messages and later transcribe the individual messages. Ultimately, the messages contain a first name, phone number, movie, date/time, etc., which I want to extract into an Excel file.

The problem

I can record the phone's normal microphone using:

MediaRecorder.AudioSource.MIC

and I can see the microphone level changing normally.

However, this only captures the phone's microphone. It does not give me the audio coming from the other party in the cellular call.

I also tried enabling the speakerphone programmatically using AudioManager, but on the Galaxy Z Fold5 the call does not switch to speakerphone.

I have also looked into InCallService, but I'm not sure whether there is a way for a normal third-party Android application to access the actual call audio/downlink as PCM data.

What I need

I don't necessarily need to record the call permanently. Ideally, I just need access to the incoming audio while the call is active so I can feed it into speech recognition.

Something like:

Cellular call
    ↓
Incoming call audio
    ↓
Audio stream / PCM
    ↓
Speech-to-text
    ↓
"7 new messages"

The target device is a Samsung Galaxy Z Fold5, running a current Android version.

I'm aware that Android restricts access to call audio for privacy/security reasons. I'm specifically looking for a legitimate Android API, Telecom API, audio routing method, accessibility approach, or device-specific solution that could make this possible without rooting the phone.

If direct access to the call downlink is fundamentally impossible for a normal Android app, I'd also appreciate confirmation of that and any practical alternatives for this specific use case.

I saw this post :
https://www.reddit.com/r/androiddev/s/bNFqQ3TqOC

I thought I'd share this new Compose API with you.

In compose 1.12.0 introduce new GradientPainter you can implement complex gradients very easily.
It is called MeshGradientPainter.
You can define the count of column and row.

For example rows = 1 and columns = 1.

The screen is divided into 4 sections and points.

This points show two things:
1.postion. Where is it? For example : 0,0 — top left.
2.color. What color is it? for example this section color is Red

And then these colors are spread very smoothly on the screen.

✅ Example:

@Composable
fun MeshGradientBackground() {
   val meshPainter = remember {
       MeshGradientPainter(
           rows = 1,
           columns = 1,
           hasBicubicColor = true
       ) {
           setVertex(0, 0, Offset(0f, 0f), Color.Red)
           setVertex(0, 1, Offset(1f, 0f), Color.Blue)
           setVertex(1, 0, Offset(0f, 1f), Color.Green)
           setVertex(1, 1, Offset(1f, 1f), Color.Yellow)
}
   }

   Box(
       modifier = Modifier
           .fillMaxSize()
           .paint(meshPainter)
   )
}

I'm currently looking for feedback to improve it. What do you guys think of the UI and the overall look? Any features you'd like to see added?

Been going through our app's integrity checks and realized most of what we have is still the old client-side stuff — checking `Build.TAGS` for test-keys, looking for `su` binaries, checking known root package names. All of which Frida can hook around in about five minutes if someone actually wants to bypass it.

Curious what people are actually running in production in 2026. Anyone fully moved to Play Integrity API with server-side verdict checking? What was the migration pain — I'm mostly worried about false positives on rooted-but-legitimate power users, and how much complexity nonce binding adds to a normal auth flow.

Not looking for a lecture on "client-side checks are theater" — I know. Looking for what people actually shipped and what broke.

Hey everyone, beginner Android dev here. I just finished building a LocationApp tutorial (live tracking and geocoding). I didn't just blindly follow it; I actually get what's happening under the hood and even built a custom Jetpack Compose UI instead of using the instructor's layout.

I’m feeling super comfortable with Compose and the UI side of things. But when it comes to the logic side—like setting up Retrofit or Coil for the first time in a project—my mind just goes blank. I can never write it from scratch and always end up copying from my previous projects to get it wired up.

• Is this normal? Do you actually memorize all this setup code, or is referencing old projects just part of the job?
• What are your best tips for speeding up my learning progress when it comes to the logic and architecture side of Android?

Am I missing something or is it currently not possible to emulate new pixel lineup in AS?

One of our users with Pixel 11 Pro is having some issues with videos in our app. I think is a long shot to test this on emulator anyway but was surprised that these phones are not available in AS yet.

Hi folks. I made a new site called ComposeGradients.com

There was no place to browse beautiful gradients for Compose apps so I decided to build one.

The site has a plethora of beautiful looking gradients (linear and mesh), plus a small tool to create gradients straight from the browser.

✅ Browse beautiful gradients and copy their code

✅ Create your own gradients

✅ (Optionally) Submit your gradient to the site

You can Like your favorites by pressing the heart button. No account required.

Try it out at ComposeGradients.com

If you find the site useful, share the site with your friends :)

If you use the Android Emulator on Windows, Google now recommends using Windows Hypervisor Platform (WHPX) instead of the Android Emulator Hypervisor Driver (AEHD).

Google says AEHD will be sunset on December 31, 2026, so Windows users should begin switching to WHPX. WHPX is the better long-term option, especially if you also use Hyper-V, WSL2, Docker, or other virtualization features.

You can check your emulator’s acceleration with:

emulator -accel-check

(you need to add emulator to your PATH, found under "%LOCALAPPDATA%\Android\Sdk\emulator\emulator.exe")

The result should show that WHPX is installed and usable.

Official documentation: https://developer.android.com/studio/run/emulator-acceleration

I'm planning to release a paid app on Google Play, but I've run into a roadblock: merchant/payment profile registration isn't supported in my country.

I've looked through Google's official documentation, and I can't find any alternative process for developers in unsupported regions.

I posted my interactive Globe animation recently, and a lot of you liked it!

So I decided to open-source it, so you can use it in your own projects, contribute to it, or help make it even better.

Original post: https://www.reddit.com/r/androiddev/s/SgRoDszioN
GitHub: https://github.com/wailbabou/JetpackGlobe

Feel free to check it out, and any feedback or contributions are welcome!

I want to implement the "widget on lock screen" feature for my app. and I don't have a physical Android device that supports that feature. So I'm hoping to test it on the virtual device emulator in Android Studio (Android Studio Quail 1 | 2026.1.1 Patch 2). But I have tried installing system image Android 16, Android 17 and Android 17.1, but I still can't find the "Widgets on lock screen" in the Setting screen. I have tried setup lock screen, and tried find in the 'Wallpaper & style" -> "More lock screen settings" screen but it's not there. What am i missing?

Our Play developer account got terminated about a year and a half ago for "prior violations." Never got a straight answer on what that actually meant, best guess is it got linked to some other account somewhere. The app is boring internal stuff, a delivery fleet app our own drivers and partner shops use. We've just been handing out the APK from our own site since then and honestly it's been fine.

That obviously stops working once developer verification goes global. So the plan was to register with the Android Developer Console instead, since that's supposed to be the path for people distributing outside Play.

Except I can't find anywhere that says whether that's even allowed if you've been terminated from Play. The verification docs don't mention it, the ADC help pages don't mention it, and every time I search it just turns into results about Play Console bans, which isn't the same thing.

So has anyone actually tried this? Terminated on Play, then registered ADC. Did it go through, get rejected, or go through and then get pulled later?

Hey all — I'm maxrave-dev.

Three years ago I started SimpMusic — a FOSS music client in Kotlin and Compose Multiplatform — because the app I wanted didn't exist and I figured I could learn by building it.

Today it runs on Android, Windows, macOS and Linux, and it's sitting at almost 11k stars with real users on F-Droid and GitHub releases. I'm saying that not to flex: I'm 23, for most of those three years I had no senior to ask and nobody reviewing my code, and I learned almost everything the hard way — Media3 internals, Room migrations at real-user scale, Glance widgets, a native media engine bound over JNA, desktop packaging and code-signing. There's plenty in the codebase I'm still not proud of. Some bugs cost me whole days. A couple are honestly embarrassing.

But I kept notes. Every time something burned me — a Media3 quirk, a migration gone wrong, a Compose trap — it went into my personal notes: messy, half-finished, scattered all over the repo.

Recently I turned those hand-written notes into something more useful: a skills pack for coding agents. 224 short markdown docs in the agent-skills format, so Claude Code / Cursor / Codex can pull the right doc exactly when you hit the same problem (`npx skills add maxrave-dev/kotlin-footguns`) — but it's all plain markdown, and it reads fine as a human reference too.

To be clear, this isn't an AI dump with my name on it. Every doc follows one structure — what breaks, the mechanism behind it, and commands you can run to check whether your own codebase has the same problem — and every claim was verified against the real tree before shipping. The notes and the scars are mine; the agents just helped me make three years of mess consistent.

https://github.com/maxrave-dev/kotlin-footguns

GPL, plain markdown, free. I'm sure some docs still have mistakes — I'm still learning. If you spot one, tell me. That's the whole spirit of the thing.