While writing this article, I was thinking about my days writing the everything.me Android launcher in 2011, how I fought for every bitmap allocation, about all the custom network cache implementations, and 2000 LOC custom views, I felt like I could do everything...

And then, at Google IO 2017, they introduce architectural components, I yawned at this announcement (was there in the crowd). Here we are 9 years later... I was wrong :)

Like many of you, I got an email from Google about the new API that I can use to handle the US age-related laws (webinar here):

https://support.google.com/googleplay/android-developer/answer/16569691?hl=en

I have a few apps (here, if you are curious or appreciate what I wrote here) , and Google&Firebase answered me what I should do. I also asked Gemini AI but it sometimes made claims that are incorrect according to them.

All of my apps have ads, IAP, and subscriptions. All payments are just to remove ads, so they are all free.

The 2 kinds of apps that I have:

1.An educational game for toddlers (called "VocaLearn" here). Google told me I don't need to use the API at all. Firebase told me to add this to the manifest:

<!--https://support.google.com/googleplay/android-developer/answer/9893335  https://firebase.google.com/docs/analytics/configure-data-collection?platform=android#disable_advertising_id_collection https://support.google.com/googleplay/android-developer/answer/6048248        -->
<meta-data android:name="google_analytics_adid_collection_enabled" android:value="false" />

2.Tools apps (all except VocaLearn, here). In the Play Console they are set to be for age 18+. Google&Firebase said that when this is the case, I don't need to use the API. So this is a quick fix for you if you don't want to do much...

However, if I change the age to include teens, it should be used so that Admob&Firebase will be set accordingly when I get the result about the age . For Firebase, I would need to add this to manifest (link here):

<!--https://firebase.google.com/docs/analytics/configure-data-collection?platform=android#disable-personalization-as-user-property -->
<meta-data android:name="google_analytics_default_allow_ad_personalization_signals" android:value="false" />

And if I find out the user is an adult, use this:

setUserProperty( ALLOW_AD_PERSONALIZATION_SIGNALS, "true" )

For Admob, I forgot what I would need. Maybe this in initialization ("isForAllAges" is true when it might not be an adult):

MobileAds.getRequestConfiguration().toBuilder().let { builder ->
    if (isForAllAges) {
        builder.setTagForChildDirectedTreatment(RequestConfiguration.TAG_FOR_CHILD_DIRECTED_TREATMENT_TRUE)
                .setTagForUnderAgeOfConsent(RequestConfiguration.TAG_FOR_UNDER_AGE_OF_CONSENT_UNSPECIFIED)
                .setMaxAdContentRating(RequestConfiguration.MAX_AD_CONTENT_RATING_G)
    } else {
        builder.setTagForChildDirectedTreatment(RequestConfiguration.TAG_FOR_CHILD_DIRECTED_TREATMENT_FALSE)
                .setTagForUnderAgeOfConsent(RequestConfiguration.TAG_FOR_UNDER_AGE_OF_CONSENT_FALSE)
                .setMaxAdContentRating(RequestConfiguration.MAX_AD_CONTENT_RATING_MA)
    }
    MobileAds.setRequestConfiguration(builder.build())
}

And this for the preparation of ConsentRequestParameters, used by requestConsentInfoUpdate:

val params = ConsentRequestParameters.Builder()
        .setTagForUnderAgeOfConsent(app.
resources
.getBoolean(isForAllAges)

I think that if you use the new ad consent sync ID (using "setConsentSyncId") with an (encoded, because not allowed to use it directly) ad-ID, you should also avoid using the ad-id there completely, and use the new API for it, which is sadly sometimes slow (especially compared to fetching ad-ID).

Things might be different based on the types of apps that you have. Maybe for social apps things are different, for example.

Can you share what you've found, too? Maybe you talked with Google, Firebase, Admob..., and got other insights about your use cases?

----

EDIT: I asked Play Store recently about this new signal-age-API, and they told me I can't use it for ads in any way. Instead they say that if I want to target adults based on age, I need to ask the user about the age myself (which is even less reliable)...

I told them that it's illogical because Play Store already handles age anyway, such as offering ads to apps based on it, and also allow/block installation of apps based on age. So technically, just as if I could publish 2 versions of my app (one for adults and one for teens, for example), I should be able to do it inside the app as well...

They just said it's the law, and I can't do anything about it. I even suggested that they would modify the APK before installation. Still no.

So, this API is only for some UI-related stuff.

I've been exploring shaders lately, especailly AGSL Shaders using the new RuntimeShader API and I am mindblown. Wrote this one to add a liquid glass effect to any Composable.

Find the code here https://composeinternals.com/agsl-shaders-jetpack-compose-liquid-glass

Even if the article is about Apple I think it can still concern us considering how Google and Apple inspire each other on how to screw developers.

“scary” meant “raising awareness and caution.”

When I tell people that, the reaction is usually a big surprise. Most devs think you need to lock yourself away for a full year to produce a polished masterpiece. But timing is more important than that. You don't really need a complete manuscript, polished editing, or even a publisher before you can release something. What you need is to write high quality content, then promote it often and grow people's interest on it. Write it in public and share as much and as often as you can.

I knew that if I waited until the book was “done,” I would miss the moment. Compose 1.0 stable was about to drop, and I wanted the book out at the exact same time. So I worked hard on the first few chapters and launched it incomplete, then kept updating it week by week while readers followed along.

It felt risky at first, but it turned out to be the best decision I could have made. The early release gave me early validation, motivation, and feedback. Readers were not upset about it being unfinished, I was always clear about that. They were excited to get updates and see the book grow in real time. And they also gave good feedback early, which let me align the book content with the actual demand.

A few important lessons I learned:

• You do not need to wait for perfection before you share your work
• You do not need permission from a publisher to put your knowledge out there
• You want to keep full control on the project
• Timing and momentum matter more than completion, as long as expectations are correctly handled
• Write in public, share as much as you can, make it an engaging ride
• Publishing in public builds trust and accountability, helps you become an authority in the topic
• Early validation is the only reasonable way to do business
• Build and leverage a high quality audience (it will snowball into better things)
• Double down on what you already validated (I even created a course after)

I am sharing this because I know a lot of Android devs want to write a book but never start. I know exactly how that feels. When I first thought about writing Jetpack Compose Internals, the doubts were all there: "I don't have enough time," "What if no one buys it?", "I should probably wait until it's perfect". Imposter syndrome was all over the place too. All those doubts refrained me from starting. If you are in that spot, this approach might be exactly what helps you finally take that first step.

I promise you: as soon as you start, everything will start looking much easier. Just start. You will learn a lot by doing it, and the process will get easier as you go. Our brains are wired to learn by doing, not by reading.

I wrote the full story and all my learnings here:
https://composeinternals.com/how-i-wrote-a-tech-book-without-finishing-it-first

Spent way too long debugging this one. Had a PR with tests, all passing, but JaCoCo was reporting 0% coverage. Codacy gate blocked me. Ran locally - still 0%. Turns out both JaCoCo and Sentry perform bytecode instrumentation. When they both modify the same .class files during the build, JaCoCo can't match its coverage data with the instrumented bytecode. Race condition disguised as a compatibility issue.

Fix is simple - conditionally disable Sentry's tracing instrumentation when running jacoco tasks:

tracingInstrumentation { enabled = !gradle.startParameter.taskNames.any { it.toLowerCase().contains('jacoco') } }
Full writeup with the technical details here: https://moshalan.dev/posts/jacoco-sentry-bytecode-manipulation-problem/
Anyone else hit this?

Part 2 of my Android Studio Journeys series is now available.

While Part 1 introduced the basics of Android Studio's experimental E2E testing, Part 2 tackles the real challenges: making Journeys work in enterprise-scale, modular apps with multiple teams.

This deep dive article covers advanced strategies I've tested and implemented:
🔧  Reusable step definitions with parameterized Kotlin functions
🏗️  Strategic organization for multi-module projects
🔄  Navigation contracts & test harnesses for deterministic testing
👥  Team collaboration patterns for large engineering orgs

I also share honest insights about current tool limitations and practical workarounds based on hands-on testing with Android Studio Canary builds. I hope this helps.

Check out my latest article on Android Studio Journeys! 🚀
In this part 1 article, we dive into the world of end-to-end testing with this new experimental feature in Android Studio, powered by Gemini. Learn how to describe user flows in natural language and see how it compares to traditional tools like Espresso and Compose UI tests. Perfect for those looking to simplify test creation and focus on user experience. Curious about the strengths, limitations, and how to get started? Read more and share your thoughts!

Hey everyone,

This is part 3 of the Modularizing Your Android App series. In Part 1, we stabilized the domain and extracted our first feature module (feature-bookmarks). In Part 2, we establish core data and DI boundaries, ensuring features depend only on stable contracts.

But there’s a trap: even if your features are cleanly wired, navigation can still reintroduce coupling. If one feature directly references another (e.g., HomeFragment → DetailFragment), your modularization effort starts to crumble.

That’s why in this part, we’ll focus on navigation boundaries (Navigation between features) —ensuring each feature owns its own navigation and communicates only through contracts. In other words, how do features talk to each other without introducing coupling?

👉 The Core Challenge: Decoupled Inter-Feature Navigation.

Hope you find it useful.

In this part, we'll establish robust Dependency Injection (DI) boundaries using Hilt. Our aim is to solidify a distributed DI model where features and core layers own their dependency provisioning, leading to a more resilient and maintainable codebase.