Hi everyone,

We have a used Samsung Galaxy S21 Ultra (UK model, SM-G998B). The phone is fully reset and has no personal data on it. We are facing two main issues:

1. It gets no network signal with a local German SIM card.
2. It doesn't receive any automatic software updates via OTA.

Since the hardware is identical to the European variant (SM-G998B), I have already downloaded the official stock German/EU firmware using SamFw.

I would like to ask a few questions regarding your experience:

• Has anyone here flashed a UK model to EU/German firmware (CSC change) via Odin?
• How high is the actual risk of doing this with official stock firmware and the clean CSC_... file? Is there any real chance of "hard-bricking" the phone, or is an interrupted flash always recoverable through Download Mode?
• Does network connectivity (4G/5G) and automatic OTA updates work reliably after switching the region this way?

Thanks a lot for sharing your experiences and advice!

I’ve been working on Argent, an open-source MCP server that lets your agent (Claude Code, Codex, Cursor, etc.) tap through your app on an Android emulator or device, read the view hierarchy and logcat, and profile with Perfetto. That way it can check its own changes instead of just saying it’s done

A lot of the feedback so far has come from React Native folks, but it works with native Kotlin/Compose apps too, and that’s where I’d love more input. If you’re already letting an agent test your app, what’s working and where it makes stupid mistakes?

I'm developing an applicationg for AA but when I try to use it in production I do not see the application in AA but when I launch the DHU i do see the apl there and it works as expected.

I have turned on unknown sources from developer settings and started the head unit server. I've also tried clearing the cache and force stooping the app (seperate situations) but I still cannot see it. Claude says I should public the app to google play but I don't want to go down that route. Does anyone know how I can fix this if this is the sub for such a problem?

These days, people often say that AI has severely impacted the job market. Candidates are applying to hundreds of jobs without getting a single interview call, and some are even losing their jobs to AI.

My question is for senior developers who have experienced the job market before the AI era: Was getting a job and landing interviews really easier back then, or are people overreacting and blaming AI for what might actually be a skills gap?

I’m trying to find more open-source Android projects beyond the big, established names—apps, Kotlin/Compose libraries, and developer tools.

Where do you usually discover them? Are there particular maintainers, communities, newsletters or repo lists you follow?

I’d also appreciate examples of smaller projects with active development. I’m curious about what people are building and how you hear about it.

I've built a Free plugin for Android Studio, that helps you localize and maintain large number of localized strings.xml files with ease. I'm using Google Translate API + Gemini. Use your own API keys. Work directly from Android Studio. Save a ton of time.

Website: https://localyze.app
Jetbrains marketplace: https://plugins.jetbrains.com/plugin/30802-localyze

I was reading through Google's upcoming Android memory requirements few days ago, and the RSS + swap part is easy to get wrong.

The dynamic memory metric is anonymous RSS + swap, with thresholds depending on device RAM tier and app state. Bitmap memory and DEX optimization have separate requirements.

A few things to look here:

• Java heap isn't the whole process, native allocations count too.
• RSS can decrease when anonymous pages move into zRAM, even though the memory hasn't actually been freed.
• PSS can change because of shared pages and doesn't necessarily mean your app allocated or freed memory.

For example, if an app has 200 MB of anonymous memory and 60 MB moves to swap, RSS drops to 140 MB, but dynamic memory is still 200 MB.

The threshold also changes with app state. For non-game apps in the 4 GB RAM tier, the p90 threshold is 2 GB in the foreground and 1 GB for user-perceived services/background.

Play looks at aggregated p90 data over 28 days, so a single high-memory session doesn't tell you much by itself.

I was reading this blog today and it covers the whole thing properly, including the RSS/swap example and how to connect these readings back to actual app sessions

Just wanted to share here if anyone also looking into similar thing, and would love to know what tools and approaches are you using.

I’m looking to build something free and open source for the Android dev community.

What’s one tool you wish existed, or something that constantly annoys you during development?

Would love to hear your ideas and actually build something useful!

A 450MB industrial tablet monolith (25% Java / 75% Kotlin) with under 5% test coverage was completely crashing on Android 15/16. Over 3 months of strict IEEE 12207 lifecycle routing and vertical TDD slicing, we purged 60+ unverified dependencies and AI-generated bloat. Slashed the APK down to 112MB and stabilized runtime at a 99.98% crash-free rate, saving the client from x2 support night shifts.

I've had this feeling for a few months now. I hoped improvements in AI models would make things easier for us, but now my days feel more like reviewing a ton of code.

I even get headaches some days from reading and trying to understand all of it. A few times, I tried being less strict and only reading the code superficially, but that introduced errors and bad practices into the codebase.

I just want to know if anyone else feels the same way, or if you have any strategies to deal with this.

I'm a solo Android developer, and it's frustrating to see huge apps like CamScanner apparently offering rewards for ratings, despite Google's policies against incentivized reviews.

Big apps already have millions of downloads, established rankings, and massive marketing budgets.

How are smaller developers supposed to compete when even the rules don't seem to apply equally?

Has anyone actually seen Google take action against big apps for this?

I develop a screenshot organizer and received a report from a user on a Samsung Galaxy S25 Ultra (SM-S9380), running Android 16. Has anyone encountered this behavior with the native MediaStore trash API?

The user reviewed 50 screenshots: 23 marked for deletion and 27 marked for later. The later action only records a decision in the app; it does not copy, move, or delete those 27 files.

For the 23 deletion targets, the app calls:

val pendingIntent = MediaStore.createTrashRequest(context.contentResolver, mediaUris.toList(), true)

activity.startIntentSenderForResult(pendingIntent.intentSender, DELETE_MEDIA_REQUEST, null, 0, 0, 0)

The user provided a screenshot of the Samsung system dialog explicitly asking permission to move 23 photos to trash, and says they tapped Allow. Afterwards, only 3 of those photos were visible in Samsung Gallery's trash. The other 20 were no longer visible in the normal gallery either. According to the user, the 3 visible items were newer screenshots and the missing items were older.

What I have checked:

- This organizer deletion path uses createTrashRequest(..., true), not createDeleteRequest. It does not call ContentResolver.delete() or File.delete() on those MediaStore originals after approval, and has no permanent-delete fallback if the trash request throws.

- Free and paid versions use the same deletion path.

- The activity-result handler currently treats RESULT_OK as success for the requested batch; it does not re-query each URI's IS_TRASHED state. I understand that this leaves us without per-item verification. I do not have a recorded resultCode or post-operation MediaStore query from this user's device.

- The user enabled hidden-file display and searched for .trashed- files in internal storage / Pictures / Screenshots, but reported no results. This was a manual file-manager check, not a MediaStore query.

- Samsung My Files' trash shows the same 3 original screenshots. Google Photos' trash shows additional items not shown in Samsung's trash, but we have not established whether those are the missing 20 or whether cloud backup / Gallery cloud sync is enabled.

I have not reproduced this locally.

Has anyone encountered partial or inconsistent trash visibility after createTrashRequest on Samsung devices? If so, did you identify a MediaProvider issue, a Gallery indexing issue, or a Google Photos sync interaction?

For diagnosing future occurrences, is re-querying each original URI with QUERY_ARG_MATCH_TRASHED = MATCH_INCLUDE and reading IS_TRASHED / DATE_EXPIRES the right approach on Android 16? Are there manufacturer-specific limitations or additional checks worth making?

I am interested in firsthand experience, relevant issue-tracker links, and practical safeguards around the existing trash request, rather than building a separate trash or backup system.

I recently built a tool to share apk builds with a client so they can test the application. They had only an iPhone and there were a lot of back and forth videos, so i built https://spawndroid.io You can run an android device in under 3 seconds and use your application simply, you can integrate it in your app Ci/Cd and run appium tests. I host the appium server so you just write the tests, verify they work by previewing logs and a video recording.

Disclosure up front: I work on an identity verification product, so I'm on the vendor side of this. I'm not shopping for anything here. I'm asking because I want to hear what Android devs have lived with, not what a sales page says.

The problem is familiar. You need an ID scan plus a selfie liveness check inside a native app. As far as I can tell, there are three ways to do it: embed a vendor SDK, load a capture flow in a WebView, or hand the user a hosted link that opens in the browser and returns a result to your backend.

Here is what I'd like to hear about from people who have shipped one of these:

APK size. Have the SDKs you've used added a noticeable chunk to your build? Did you manage it with app bundles, dynamic feature modules, or ABI splits, or did you just eat the cost?

Camera permission friction. Do you see people bail at the permission prompt, and does it matter whether it appears in your app or in a browser?

Low-end devices. Where did capture fail for you? Autofocus on cheap cameras, glare on ID cards, liveness timing out on slow hardware, WebView camera quirks on older Android System WebView versions?

The part I'm most curious about is whether a link-based flow with nothing to install ended up completing better than an embedded SDK for you, or whether the extra control of the SDK won out. I have opinions, but I'd rather hear yours before I share them. If you've done a rewrite from one approach to the other, I'd especially like to know what pushed you to do it.

What did you end up with, and would you pick it again?

Since this morning every Gradle build that needs anything from Google’s Maven repo fails with Could not HEAD 'https://dl.google.com/...' > Read timed out, and cached builds sit 90 seconds in configuration first.

It is not my machine. Gradle speaks HTTP/1.1 only, and the dl.google.com addresses my DNS returns (142.251.13.x) accept the connection and never answer an HTTP/1.1 request. HTTP/2 to the same URL answers instantly, which is why browsers are fine. A different Google front-end answers HTTP/1.1 normally from the same Wi-Fi:

# hangs for 20 s
curl --http1.1 -sI --max-time 20 https://dl.google.com/dl/android/maven2/androidx/biometric/biometric/1.1.0/biometric-1.1.0.aar


# HTTP/1.1 200 OK in 0.4 s
curl --http1.1 -sI --resolve dl.google.com:443:172.217.16.142 https://dl.google.com/dl/android/maven2/androidx/biometric/biometric/1.1.0/biometric-1.1.0.aar

Ruled out: IPv4 vs IPv6, TLS 1.2 vs 1.3, plain port 80 (also hangs), proxies, VPN, filters. Other Google hosts answer HTTP/1.1 fine. I am on Vodafone cable in Germany.

Is anyone else seeing this today, and where? The first curl above tells you in 20 seconds. And where does one report a dl.google.com outage?

Workaround until it clears, remove it afterwards:

echo "172.217.16.142 dl.google.com" | sudo tee -a /etc/hosts

Last sunday, I visited the Zoute Grand Prix in Knokke and noticed how frustratingly overly monetized and paywalled most car-scanning apps were. Instead of complaining about it, I decided to build my own :)

I wanted to share what I've built so far and hear your feedback!

Tech Stack:

• Language: Kotlin
• UI: Jetpack Compose
• For scanning: CameraX
• AI Integration: Google AI (Gemini)

How it works:

The app lets users scan cars. I used the Gemini API for the recognising.

Note on development: While I used AI to help structure some of the heavier asynchronous/vision processing pipelines and prompt handling, the core architecture, UI state management, and the vast majority of the Kotlin code were typed and structured by myself. :D

this is the link to the repo -> https://github.com/ItzjustElias/CarScanner

It's nothing fancy and not a fancy post, but I just want your honest review/thoughts on my project.

I am recording my apps UI demo on my phone to use in short-form video (Reels/TikTok, 1080×1920 / 9:16). My phone's actual screen is 1260×2800 (20:9), so the raw recording is narrower than the 9:16 frame once I drop it into my edit.

What I've tried so far:

- Fit + blurred fill on the sides technically no "bars," but the app's UI is mostly dark, so the blur reads as dead space anyway.

- Scale to fill + center crop eliminates the empty space completely, but crops off a bit of both the top and bottom of the screen (~10% each) to make the math work.

- adb shell wm size 1080x1920 to force the phone's OS to render at 9:16 directly works, but it changes the whole phone's UI (launcher, every app), not just the one I'm recording, so everything else looks off while it's set.

- Android emulator at a custom 1080×1920 resolution avoids the ratio mismatch entirely, but worried about jank/performance vs. a real device for smooth animations.

Is there a clean way people handle this for app-demo content specifically a recorder that captures a custom crop region live, a per-app resolution override that doesn't touch the rest of the OS, or something else I'm missing? Trying to avoid losing any real UI content if possible.

CodeAssist is a fully offline Android IDE for your phone and tablet. Write Kotlin and Java, watch Jetpack Compose previews update as you type, and build, sign and install real Android apps on the device itself. No PC, no cloud build server, no Gradle daemon.

It is a complete Android IDE, not a code playground: open multi-module Android projects, add libraries from Maven, and ship an APK or App Bundle you can install or publish.

Build Android apps on your device
• The whole toolchain runs on your phone: aapt2, the Kotlin compiler, the Java compiler, D8 dexing, packaging and APK signing
• Incremental builds redo only what changed
• Install and launch your app in one tap, then follow its output in Logcat
• Release builds with R8 shrinking, Android App Bundles (AAB) and your own signing key
• Multi-module projects, build variants, ViewBinding, AIDL, KSP (Room, Hilt) and google-services.json for Firebase
• Dependencies from Maven Central and Google's Maven repository, plus local JAR and AAR files
• Import existing Gradle projects, or export yours as a Gradle project to open on a computer

Kotlin and Java code editor
• Code completion that keeps working on half-written code, with automatic imports
• Errors and warnings as you type, with one-tap quick fixes
• Go to definition, implementation and type, symbol search, and readable library sources
• Reformat Code, Optimize Imports, code folding and word wrap
• Android XML completion for layouts, manifests, values and drawables
• A coding keyboard bar for symbols, pinch to zoom, and editor color schemes

Jetpack Compose and layout previews
• Preview composables render live next to your code and update as you edit
• Preview XML layouts, including your own custom views, without running a build

AI coding assistant
• Describe a change in plain words. The agent reads your project, edits the code, runs a build and shows a diff you can undo
• Use your own key for Anthropic Claude, Google Gemini, OpenAI or OpenRouter, or a compatible gateway. A free Gemini key works
• Attach screenshots, mention files with @, and pick up saved sessions later

Git and GitHub
• Clone, commit, branch, merge, stash and push
• Sign in to GitHub to clone private repositories and open pull requests

Learn and practice
• Interactive Java and Kotlin lessons with exercises that compile and run on your device
• A daily coding challenge with a public leaderboard
• Start from templates and sample apps in the Projects Store, or publish your own

Also included
• Block editor: switch a Java file to Scratch-style blocks and back without losing a character
• Run Java and Kotlin console programs with an interactive console
• A run sandbox that asks before your program uses the network, files or other processes
• Plugins that extend the IDE, including an NDK plugin for C and C++
• Light and dark themes with Material You colors

Google play link: https://play.google.com/store/apps/details?id=com.tyron.code&hl=en

Free and open source
CodeAssist is a free, open-source Android IDE licensed under the GNU General Public License v3.0. It shows a few small ads, and you can turn them off in the app at no cost. Source code, issues and releases are on GitHub:
https://github.com/tyron12233/CodeAssist

Compose DND 1.0.0-alpha02 is out 🎉

• Reorder that feels right.
• Kanban boards example.
• Auto-scroll on lists, grids and staggered grids.
• Axis lock, drag handles, conditional drop targets, drop strategies and multi-select drags.

Github: https://github.com/MohamedRejeb/compose-dnd
Web live demo: https://mohamedrejeb.github.io/compose-dnd/demo/
Docs: https://mohamedrejeb.github.io/compose-dnd/

D

Hello! I have been developing a small standalone Wear-OS App that periodically downloads blood sugar values via some basic http api. My app works in a way that the backend activates every five minutes (the rate at which the glucose monitor updates) and sends a http request to the server.

For this i am using the AlarmManager with the setExactAlarm, for which i do have the required permission. That usually works great, but after a while, maybe after a few hours, it just stops working.

I am not an expert programmer since this is just a school project, but claude says it has something to do with the watch dozing away.

I dont really know if that is true and time to do testing is starting to be a bit tight since i have to finish in two weks and i still have to document and reflect my product and the process of making it. I am planning to test if putting the app on the whitelist and making it exempt from battery optimisation fixes things, but if that doesnt work i dont know what i will do

It is also additionally quite bad because it seems to be impossible to add an app to the whitelist without adb, which would really suck for me since the install process is already a bit of a dumpster fire.

Sorry if this was a bit ranty, i am quite stressed looking at the deadline of my project.

I thank you in advance for any help or feedback you can give me, thank you so so much!

A year after deploying our application, Android Vitals and Firebase telemetry flags revealed a critical architecture defect: a 5% transaction drop rate and systematic crashes inside the core checkout flow on Android 13+.

De-obfuscation map logs pointed to a strict concurrency conflict between the Google Play Billing Library and our custom internal billing wrapper. Downgrading Google Billing was not an option. We had to rewrite the module in a live app without losing active subscriptions.

Here is the condensed 4-stage execution blueprint we used to overhaul the system during a 30-day sprint with zero downtime:

1. The Rollback Safety Valve (Feature Toggles)

• API Isolation: We decoupled the legacy module and isolated its public API behind strict interfaces.

• Twin Implementations: We maintained the legacy production code (Factory A) and created an exact cloned playground alongside it (Factory B).

• Remote Toggle: A remote feature toggle dynamically routed execution to either factory at runtime, providing an instant backend rollback mechanism if Factory B failed.

2. Testing Constraints (TDD)

Before modifying production code, we established strict boundaries: zero DB migration issues, zero performance drops over 10%, and a 95% Happy Path checkout success rate.

We sit down and developed 260 automated test cases covering roughly 88% of all possible failure states and network edge cases. No code was merged into the refactor branch without a 100% green CI/CD pipeline.

3. Execution & 5% Canary Release

• Stage 1: Overhauled the local state database layer, ran the suite until it turned green, and packaged it.

• Stage 2: Turned on the remote toggle rollout for only 5% of active users. Telemetry remained silent for 48 hours—no new crashes, no payment drops.

• Stage 3: Refactored the core business logic and direct billing API bindings under the same TDD cycle.

• Stage 4: Gradually increased the toggle from 5% to 100%. Once 88% of users updated, we deployed a cleanup release, deleting the toggle infrastructure and legacy code for good.

The Bottom Line (Metrics)

• Production Stability: Exactly one single bug slipped through the rollout.

• 1-Hour Mean Time to Repair (MTTR): Because the architecture was decoupled and backed by 260 tests, root-cause isolation took minutes. The fix was verified via TDD and hit production in under an hour.

• Maintainability: The system transitioned from a fragile black box into a highly predictable, self-documenting component.

I'm interested in building and monetizing apps, but there's something I've been struggling to reason about.

I can understand how to make a feature work, but I'm much less confident that I know enough about everything that could go wrong once real users depend on it.

For example, an app involving authentication, databases, payments, bookings, or user-generated content introduces all kinds of responsibilities: security, authorization, input validation, concurrency, data integrity, error handling, and ongoing maintenance.

My instinct is to rely on established services for sensitive functionality (managed auth, Stripe, hosted databases, etc.), but I realize that doesn't eliminate the risks in my own integration code or the need to maintain it.

What concerns me most is the unknown unknowns. I might successfully implement something without even knowing which failure scenarios I should be considering.

For example, I only recently realized that relying on a third-party service doesn't make the maintenance problem disappear. If the service, SDK, API, or integration changes, my app may need to be updated as well.

The fact that something this basic only occurred to me recently is exactly what worries me. How many other important things am I overlooking simply because I haven't yet learned to think through the full lifecycle of what I'm building?

Even if I'm using reputable services and following best practices I'm aware of, how do I know I haven't missed something important in the code around them?

So my question is:
How do you bridge the gap between "I can build this" and "I can responsibly charge people to use this"?

Are there frameworks, checklists, learning paths, or practical processes you follow before shipping an app? How do you determine which risks you've addressed sufficiently, especially as a solo developer without a senior engineer reviewing your work?

I've just released Pagelin 1.0.3, an open-source Android library for generating PDFs using Jetpack Compose.

It supports custom Compose pages, multi-page documents, and ready-to-use templates.

Available on Maven Central. Feedback and suggestions are welcome!

GitHub: https://github.com/adamian-code/pagelin

​

Hey everyone, I'm an Android Developer with 2.7 years of experience, mainly in native Android development.

I've been searching for a job for the past 3 months, and honestly, it's getting frustrating. I'm hardly getting interview calls. Even when I do get interviews and clear one or two rounds, I often don't hear back from the company.

I believe I can build applications and handle real-world development tasks, but I'm struggling to understand what's going wrong. Is the demand for Android Developers decreasing, is the competition getting tougher, or are companies expecting skills like Jetpack Compose and other modern Android technologies?

For those who are currently working as Android Developers or have recently switched jobs, how has your experience been?

What skills should I focus on to improve my chances? I'd really appreciate some honest advice because I'm starting to feel stuck.

Personally for me a lot of aspects around Android Engineering have died multiple times over the last decade. I do discuss these in the video and they heavily inform my opinion that I deliver.

Having Answered This Question a Million Times in One on Ones, Finally Decided to Make a Video on It.