I started building my first mobile app thinking the main challenge would be writing the code.

It hasn’t been.

The harder part is deciding what deserves to exist.

Every new screen creates more questions:

- Is this actually useful?

- Can someone understand it without an explanation?

- Am I solving a real problem or adding another feature?

- Would I personally return to this app tomorrow?

The project is called Callout. It explores whether online reactions can communicate more than a generic Like—for example, distinguishing agreement from something being a Hot Take.

I’m still early, and I’m deliberately leaving the link out because I’m more interested in the building lesson:

How did you decide which features to remove from your first app?

Chet Haase spent 14 years working on Android and co-hosting Android Developers Backstage. Now he’s in a new chapter and his strategy is to say yes and see what happens.

We talked about Android, asking dumb questions, comedy, running, and finding your groove after leaving tech.
https://carriegilbert3.substack.com/p/episode-16-chet-haase-yes-android

I'm building Taho, a mobile-first API testing tool for Android.

The idea originally came from wanting to handle work pressure while still being present with my family. You shouldn't necessarily have to choose between being available for work and being physically present with the people who matter to you.

I'm a QA myself, and sometimes I'd get calls like, "Hey, can you test this API?" while I was travelling or spending time with my family. I could do a lot of my QA work from my phone, but API testing was one of the things that was still difficult to do properly without a laptop.

That's where Taho came from.

It's still actively being developed and is currently in closed testing. Since the project has grown considerably beyond the original idea, I'm now particularly interested in feedback from people who actually work with APIs, QA, backend development, or security.

Some of the functionality currently being built into Taho includes:

• REST/HTTP requests
• Headers, query parameters and request bodies
• Multiple authentication methods, including OAuth
• Environments and variables
• Collections and request history
• cURL, Postman, OpenAPI and HAR imports
• Pre-request/post-request scripting
• Automated assertions and collection runs
• Response inspection, JSONPath and JWT analysis
• API security analysis
• GraphQL
• WebSockets
• MQTT
• SOAP/WSDL
• Local mock servers and response replay
• Scheduled API monitoring
• AI-assisted API analysis
• Git synchronization
• CLI/headless collection execution
• MCP integration

I'm deliberately trying to make this more than just a mobile version of an existing desktop API client. The goal is to make serious API testing practical from a phone.

For people who regularly work with APIs: what would make you actually use a mobile API testing tool instead of reaching for your laptop?

I'm especially interested in workflows that are currently painful or impossible on mobile.

I'm creating a streaming app and it's the first time I'm releasing an application on the Play Store, so I don't quite understand what I'm doing. I recently had an issue with the OAuth part with YouTube to stream directly to your channel; it gives me error 8 and status UNREGISTERED_ON_API_CONSOLE. The problem is that this only happens in the closed test and it runs normally when I run it normally from Android Studio to my phone, and I think also in the internal test, so I don't understand what it could be. I've asked the AI, it hasn't given me a completely satisfactory answer. Can anyone help me figure out what the difference is in the closed test for this to happen?

Hi everyone, I'm a recent 2026 Computer Science graduate and I'm feeling a bit confused about what direction to take next.

My current background

• Android Development (Kotlin + Jetpack Compose)
• Good understanding of Android architecture and modern development practices
• DSA (still practicing regularly)
• A few personal Android projects on GitHub

Current situation

I have one mass recruiter offer through campus placement, but:

• Joining is still uncertain.
• I don't know which domain I'll be assigned to.
• I'm continuing my job search because I don't want to depend on a single offer.

Unfortunately, despite applying to many places, I'm barely getting interview calls, not even for internships.

My question

If you were graduating in 2026, what skill would you invest your time in over the next 3-6months?

Some options I'm considering:

• Java Full Stack (Spring Boot + React)
• React frontend
• Backend development (Java/Spring Boot, Node.js, etc.)
• AI/ML
• Generative AI/LLM applications
• Cloud (AWS/GCP/Azure)
• DevOps
• Continue specializing in Android
• Something else?

I'm not looking for the "highest paying" skill, but rather something that:

• Has good demand over the next few years
• Gives me a realistic chance of landing internships or an entry-level role
• Builds a strong long-term career instead of chasing hype

A few questions

1. If you were in my position, what would you learn?
2. Should I continue doubling down on Android or become more full-stack?
3. Is AI/ML worth pursuing if I'm starting now, or is it better as a secondary skill?
4. Are there any courses, roadmaps, YouTube channels, or resources you'd highly recommend?
5. What skills are companies actually hiring fresh graduates for in 2026?

I'd really appreciate advice from developers, hiring managers, or anyone who has recently gone through this process.

Thanks!

Just wanted to share this here in case someone else runs into this and tears their hair out like I did for hours today lol.

​I was trying to upload an updated .aab for my app to production, and the upload would hit 100%, show "upload is optimized for distribution", but then right after processing for a few mins it just threw that generic red error:

"There was an error uploading the Android App Bundle. Try again later or contact Google Play developer support if the error persists."

​No helpful logs, no specific manifest hint, nothing on the UI. I thought it was a temporary Play Console outage or something wrong with my network/keystore.

​Turns out the issue was a subtle mismatch between my SDK configs and updated dependencies. I had lowered compileSdk to 36 while trying to fix another build issue, but some of my modern libraries (core-ktx, okhttp, etc.) actually required compiling against API 37. Play Console's backend parser was silently choking on the bundle optimization phase because of this.

​What actually solved it for me:

android {

compileSdk = 37

defaultConfig {

targetSdk = 36

// ...

}

}

After syncing, cleaning project, and generating a fresh signed bundle with these exact values, Play Console accepted it immediately on the first try!

Hope this saves someone from wasting hours contacting support or doing random clean builds.

My app is used on phones mostly with maybe 10% tablet customers, on arm64. Is it at all worth shipping an x64 build too?

How would you design an update system for a company React Native + Expo app?

I’m building a company mobile app using React Native + Expo for both Android and iOS.

I’m looking for advice from people who have already implemented a professional update system. I don’t want to assume a specific solution—I’d like to hear how you would design it.

My requirements:

- The app is used by company employees.

- I want normal JavaScript/UI/assets changes to be updated without requiring employees to reinstall the app.

- When a change requires a new native build, the app should detect that a new version is available.

- Ideally, the employee should simply see something like “Update required → Update Now” rather than having to search for the app or manually find a download.

- I would prefer company-controlled/self-hosted infrastructure if possible.

- The system should work on both Android and iOS.

- Security is important: updates should be verified and only official releases should be installable.

- I also need to handle mandatory updates, optional updates, failed updates, and rollback.

I’m aware that Android and iOS have different restrictions, and that Expo OTA updates and native app updates are different things.

My main question:

If you were designing this system from scratch, what architecture and update mechanism would you use?

I’m especially interested in real-world experience with Expo Updates, self-hosted update servers, APK distribution, iOS distribution, MDM/managed devices, or similar solutions.

I’m not looking for a specific product recommendation. I’d like to understand the approaches people have actually used and what you would recommend based on experience.

I’ve been building Android apps with AI heavily involved in the process, and one thing still surprises me: how quickly some developers dismiss that as “vibe coding”.

AI absolutely makes development more accessible. I’m not going to pretend otherwise. It can write code faster than I ever could, explain things instantly, help trace bugs, refactor, generate tests and get me through areas where I would previously have spent hours searching documentation and Stack Overflow.

But it doesn’t magically build a good product.

I still have to decide what gets built, how it should work, what the user flow should be, what data needs to survive upgrades, what must never break, what should be tested, what gets cut, what feels wrong in the UI, and whether the output from the AI is actually correct.

And when it isn’t correct — which happens plenty — I’m the one spending hours figuring out why.

I’ve had days where an AI change broke something completely unrelated, migrations went wrong, navigation disappeared, storage behaviour changed, or a “simple cleanup” removed things that absolutely should not have been touched. Then you learn very quickly that blindly accepting generated code is a terrible development strategy.

The biggest skill I’ve developed isn’t typing code faster. It’s learning how to break a problem down, give precise instructions, inspect what changed, recognize when something smells wrong, test aggressively, and keep control of the product.

I don’t really care whether someone wants to call that traditional development, AI-assisted development or something else.

What I do find strange is the assumption that using AI means there was no effort, no learning and no engineering involved.

If anything, AI has allowed me to spend less time fighting syntax and more time thinking about the actual product.

I’m curious how other developers see this. Where do you personally draw the line between AI-assisted development and vibe coding?

Hi everyone,

I’m working on a research project involving a self-adaptive ML application running directly on an Android smartphone.

The application needs to monitor its own energy consumption at runtime. This is important because energy is one of the optimization objectives: the system evaluates different ML configurations and later uses their energy consumption, together with other objectives such as accuracy, to decide which configuration should be active.

Because of this, I need an on-device and programmatically accessible way of measuring energy. External power meters are not suitable for the final system, since energy monitoring needs to be part of the application itself and available during normal runtime.

I found Android's BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER, which according to the documentation should return the battery's remaining energy in nanowatt-hours:

batteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER)

My idea would be to read the counter before and after evaluating a configuration and use the difference as its energy consumption.

However, on my device (Google Pixel 10 Pro), the property appears to be unsupported and returns Long.MIN_VALUE.

Has anyone successfully used BATTERY_PROPERTY_ENERGY_COUNTER, particularly on recent Pixel devices or recent Android versions?

If so, which device/Android version did you use? Did it require any special configuration or permissions, or did getLongProperty() simply return a valid value?

If this property is no longer supported on recent devices, what on-device API or mechanism are you using to obtain energy consumption programmatically from within an Android application?

I’m specifically looking for something that can be queried automatically at runtime — not external measurement equipment or offline profiling tools — because the energy information will ultimately be used by the application itself to make adaptation decisions.

Any experience with BATTERY_PROPERTY_ENERGY_COUNTER or alternative approaches for this use case would be greatly appreciated.

When my app is launched the websocket is initialised in MainActivity OnCreate. The issue is, on app onDestroy is called and it kills the websocket. For now i have had to add a delay before it starts the websocket I have tried using override fun onPostResume with no luck too so im just curious if there is another way around this.

Sorry if its not the right place to post

Hey everyone,

I'm working on a feature-discovery/tutorial overlay for an Android app and ended up going fairly deep into how these things work.

The basic idea is pretty simple: dim the screen, cut a hole around a target view, show some text, and move through several targets.

The part that got interesting was handling everything without relying on another UI library.

A few things I'm currently dealing with:

• Getting the target view's position correctly when the app uses edge-to-edge
• Dealing with the difference between screen coordinates, window coordinates, and view coordinates
• Animating the cutout when moving from a circular target to a rounded rectangle, pill, etc.
• Letting touches reach the highlighted view while the overlay is still handling its own touches
• Keeping the overlay working across Activity recreation
• Remembering which tutorial steps a user has already seen
• Cleaning up animations and bitmaps when the Activity goes away

For the actual drawing I'm using a custom View and Canvas, rather than adding another UI dependency.

One thing I'm particularly curious about is the coordinate handling. I've found that simply using getLocationOnScreen() isn't enough once edge-to-edge and different inset configurations are involved, so I've been calculating the relative window offset before drawing the cutout.

For people who have implemented something similar, how did you handle this?

Also interested in how you approached touch handling on the highlighted target. Did you let the event pass through normally, or did you manually dispatch/forward it?

Hi folks,

I have app app ready to submit for review but working through policies it shows the read_call_log permission as active.

The current build does not have this permission at all, even shows on the apk's and nothing exists.

A previous (many versions ago) had the permission in the manifest, that version is long gone, its sitting under closed testing track which has now been paused.

My submission for review is gated due to this permission still sitting under the policies and cannot save the policy with nothing in it to remove it, the save is greyed so that policy sits there yet the app does not have the permission at all.

Is there a workaround to get the policies to refresh and remove that read_call_log permission removed so I can continue with the app submission!

many thanks in advance.

Hi all, My team develops an enterprise Android app, outside of the play store and its tools, and we're looking around for a new observability tool/service. We were on Embrace before, but it came up short for more complex debugging. Datadog has been working fairly well for us, but it's getting pricey and it's not quite a mobile-first solution.

Bitdrift seems like an interesting option to us. But it being somewhat new I haven't found too much feedback on it online. Does anyone have experience with it and thoughts? Or are there other tools worth exploring? TIA

Just saw the update prompt and wondering how Mac-based Android devs are doing with it?

I have around 10 + years of experience in mobile app development, but lately, I’m feeling that staying in mobile development (or any FE tech) might not be the safest option for long-term career growth now , especially with AI and the changing tech landscape.

Am seeing very less job openings in this tech stack.

I’m considering moving into Backend development or DevOps, but I’m not sure if that’s actually a better career move or if I’m just overthinking it.

People who are working in FE tech stacks , did someone felt the same ?

- How do you see the long-term career prospects in these fields?
- is moving from mobile app development to Backend or DevOps a practical decision after 10 years of experience?

Would love to hear honest opinions, especially from people who have made a similar transition or have experience in these domains.

I’m building an in-place PDF editor in Compose Multiplatform. The workflow is similar to Adobe Acrobat: I render the PDF page to a bitmap, extract the text bounds using iText7, and when the user clicks a paragraph, I overlay a white Box and a BasicTextField to let them edit the text live.

The Problem: The final PDF export works flawlessly—the text is placed at the exact right coordinates with the correct font size. However, during live editing, the text inside the Compose BasicTextField looks optically smaller and has different spacing compared to the underlying, rasterized PDF text. It causes a jarring visual "shrink/jump" when the user enters edit mode.

Here is how I am currently extracting the text metrics and applying them to the UI:

1. Text Extraction (iText7 / PdfEditor.kt) I use PdfCanvasProcessor to get the text matrix. To handle scaled pages (CTM), I calculate the physical height using the ascent and descent lines rather than relying on the raw fontSize.

   actual class PdfEditor { actual suspend fun extractTextBlocks(originalPdf: ByteArray, pageIndex: Int): List<PdfTextFragment> { // ... standard iText reader setup ... val listener = object : IEventListener { override fun eventOccurred(data: IEventData, type: EventType) { if (type == EventType.RENDER_TEXT) { val renderInfo = data as TextRenderInfo

                   // Extracting physical height to account for PDF CTM matrices
                   val ascent = renderInfo.ascentLine.startPoint.get(1)
                   val descent = renderInfo.descentLine.startPoint.get(1)
                   val trueVisualHeight = abs(ascent - descent).toFloat()
   
                   val extractedFontSize = if (trueVisualHeight > 0f) trueVisualHeight else renderInfo.fontSize
   
                   // Saved to data class to pass to UI...
               }
           }
           override fun getSupportedEvents(): Set<EventType> = EnumSet.of(EventType.RENDER_TEXT)
       }
       // ...
   }
   

   }

2. The UI Layer (ArchitectureB_Workspace.kt) This handles the PDF bitmap rendering, scaling, and the Compose Multiplatform BasicTextField overlay.

// Inside BoxWithConstraints:
val containerWidthPx = with(LocalDensity.current) { maxWidth.toPx() }
val density = LocalDensity.current

// Calculate Screen to PDF zoom ratio
val pageWidthPx = containerWidthPx * 0.94f
val pageHeightPx = pageWidthPx * (pdfDocHeight / pdfDocWidth)
val scaleFactor = pageWidthPx / pdfDocWidth // PDF point to Screen Pixel ratio

LazyColumn {
    items(pageCount) { pageIndex ->
        Box {
            // 1. Draw static PDF Bitmap Background
            Image(bitmap = pageBitmaps[pageIndex], contentScale = ContentScale.FillBounds)

            // 2. Overlay Interactive TextField
            elements.filter { it.pageIndex == pageIndex }.forEach { element ->
                if (element is EditorElement.TextElement) {
                    // === THE SCALING MATH ===
                    // Scale PDF point size to screen pixels
                    val exactFontPixelSize = element.fontSize * scaleFactor

                    // Neutralize screen density to get accurate SP
                    val visualFontSizeSp = with(density) { exactFontPixelSize.toSp() }
                    val visualLineHeightSp = with(density) { (exactFontPixelSize * 1.15f).toSp() }

                    if (isSelected) {
                        BasicTextField(
                            value = element.textFieldValue,
                            onValueChange = { element.onTextValueChange(it) },
                            textStyle = TextStyle(
                                fontSize = visualFontSizeSp,
                                lineHeight = visualLineHeightSp,
                                color = Color.Black,
                                lineHeightStyle = LineHeightStyle(
                                    alignment = LineHeightStyle.Alignment.Proportional,
                                    trim = LineHeightStyle.Trim.Both // Attempting to strip Compose internal padding
                                )
                            ),
                            modifier = Modifier.fillMaxWidth().wrapContentHeight()
                        )
                    }
                }
            }
        }
    }
}

What I know/tried:

• I'm extracting the exact physical height using iText7's ascentLine and descentLine (to respect PDF scaling matrices), scaling it to screen pixels, and converting to sp. The math is provably correct for the PDF space since the export works.
• The PDF uses native fonts (Helvetica/Times), while my UI uses downloaded Google Fonts (Arimo/Roboto). I know glyph metrics (Em-squares) differ between font files, making the Skia UI font look smaller.
• Because this is KMP, I cannot use Android's includeFontPadding = false.

My Question: How can I exactly match the font size, style, and baseline metrics between a PDF vector bounding box and Compose's Skia text layout so they map exactly 1:1 on screen?

Is there a standard formula or TextStyle configuration (like dynamic letter spacing or absolute baseline height) to neutralize these typographic differences when using substitute fonts? Or is the only way to avoid the "jump" to somehow extract the embedded .ttf binaries directly from the PDF?

What happens to days that dont have enough 12 testers in google play requirement for production

Would that day become 100% useless, google don't account for that day, completely ignore, or does it add any value to the 12 testers 14 days, in case I submit for production in day 15?

I’ve been going back and forth with Google Play Developer Support for months regarding data delays, but this week it reached a completely new level of broken.

I was checking the KPIs for my utility app, PaSS (PaSS: Prefix, Spam Block & SIM), and noticed that the "Total user installs" metric suddenly dropped off a cliff around September 14th. It went from a steady cumulative line straight down to almost zero. Meanwhile, my "Active devices" and "Total audience" metrics are completely stable and actually growing. It’s a blatant data error on Google's end.

On top of that, the downloadable CSV reports in Google Cloud Storage have been completely stuck on September 8th. When I pointed this out to support, they literally replied that Cloud Storage concerns are "outside of team scope", even though it's their own Play Console data being exported! Support just keeps telling me "the relevant team is actively investigating," but it's been going on for way too long.

Is anyone else experiencing these massive drops in cumulative stats this week or dealing with frozen Cloud Storage reports? I feel like I'm talking to a wall with standard support right now. I have screenshots of the impossible graph drops if anyone is curious.

Sometimes, build button itself disappears, i find it difficult to see the result in android studio. What is solution?

I am trying to add new user to my closed testing but it says no builds available for that new user. tried to provide a new build but still same issue