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?

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 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’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.

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.

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!!

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.

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 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.

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.

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?

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 )