Here's what it says, in plain terms: starting in 2026, Google will only publish AOSP source code twice a year — in Q2 and Q4. And developers pulling the platform source should stop using the branch they've relied on for over a decade.

If you've spent any real time inside AOSP, this is a bigger deal than it looks.

What Actually Changed

Two concrete things:

1. Source drops are now biannual, not continuous. For most of Android's history, aosp-main behaved like a genuinely living branch — Google's internal platform work eventually surfaced there, and anyone syncing the repo could watch the operating system evolve in something close to real time (with obvious gaps for unreleased features). That's over. Public source pushes now happen twice a year, timed to Q2 and Q4.

2. aosp-main is being retired in favor of android-latest-release. The new manifest branch doesn't track ongoing development at all — it always points to whatever the most recent official release is (something like an android16-qprX-release tag), full stop. If you're still writing setup docs or CI configs that reference aosp-main, they're now pointing at a branch Google is walking away from.

# The old way (deprecated going forward)
repo init -u https://android.googlesource.com/platform/manifest -b aosp-main
 
# What Google now recommends
repo init -u https://android.googlesource.com/platform/manifest -b android-latest-release

One thing that isn't changing: monthly security patches. Those keep shipping on their existing android-security branches, on the existing monthly cadence, independent of the new biannual source releases.

This Didn't Come Out of Nowhere

If you've only skimmed Android news, this looks like a random infrastructure tweak. If you've been paying attention to Android platform engineering over the last two years, it's the next step in a pattern:

• Google has been rolling out Trunk Stable, an internal development model that replaces long-lived feature branches with everything landing directly in one internal main branch, gated by feature flags instead of branch merges. It's part of why Android 16 shipped ahead of Android's usual yearly cadence.
• Around 2025, Google stopped folding Pixel-specific changes into AOSP altogether, shifting toward developing new releases entirely inside closed internal branches before pushing a finished snapshot out.
• Components that used to get meaningful public development in the open — the Bluetooth stack, the build system, the update engine, parts of the virtualization framework — have been quietly pulled back behind the same wall. Put together, the story isn't "AOSP publishes less often." It's "the era of watching Android get built, live, in public, is basically over." What you get now is a finished release, dropped twice a year, rather than a running commit history you can follow.

Why This Actually Matters (Even If You'll Never Clone AOSP)

Google's own framing is that this is developer infrastructure — nothing a regular Android user will ever notice. That's true for app developers targeting the SDK. It's not true for a decent-sized chunk of the ecosystem:

• Custom ROM projects (LineageOS, GrapheneOS, and the dozens of smaller device-specific projects) rebase their work on top of AOSP. Two source drops a year instead of a rolling stream means longer gaps between the moment Google fixes or breaks something and the moment ROM maintainers can even see the diff.
• OEMs and chipset vendors who fork AOSP for their own device lines lose the ability to track platform changes incrementally, which makes it harder to catch integration issues early instead of all at once, twice a year.
• Students, researchers, and engineers learning AOSP — historically one of the best ways to actually understand how Android works under the hood — now learn from a periodic snapshot instead of a living project with visible commit history and rationale. None of this breaks anything overnight. It just quietly narrows who gets to watch Android being built, and turns AOSP from something closer to "an open project" into something closer to "a release artifact with source code attached."

What To Actually Do About It

If you touch AOSP in any professional capacity, the action items are small but worth doing now, before your tooling breaks on the next drop:

1. Swap aosp-main for android-latest-release in any repo manifests, CI pipelines, or onboarding docs your team maintains.
2. Stop expecting incremental platform commits between releases. Plan integration and testing work around two windows a year (Q2, Q4) instead of continuous syncing.
3. Keep security patching on its own track — android-security branches are unaffected, so don't conflate your platform-tracking strategy with your patch strategy.
4. If you maintain a fork or a custom build, budget more review time right after each release drop — you'll be absorbing roughly six months of platform change in one sync instead of catching it incrementally.

The Bigger Question

None of this makes Android closed source — the code is still released, still under the same license, still buildable by anyone. But "open source" was never just about the license. Part of what made AOSP genuinely useful to the wider ecosystem was that you could watch it happen — see the commits, understand the reasoning, catch problems early.

That part is what's quietly going away. Google didn't announce it at I/O. It showed up as a banner on a docs site, worded like a routine infrastructure update. Maybe that's exactly what it is. Or maybe it's the clearest signal yet of how much of Android's actual development has already moved behind closed doors — and how comfortable Google now is admitting it in a single paragraph nobody was meant to read twice.

Are you affected by this change — building a ROM, maintaining a fork, or just learning AOSP? I'd like to hear how teams are adjusting their workflows for the new release cadence.

Sources: source.android.com · AOSP Automotive release notes

After years building large, multi-module Android apps, I've found the difference between a Compose codebase that scales and one that turns into spaghetti almost always comes down to a handful of component design habits. Here's what actually holds up in production.

1. Stateless composables are your default, not your exception

The single highest-leverage habit in Compose is state hoisting: a composable shouldn't own state it doesn't need to own. Push state up to the caller, and let the composable just describe how to render it.

// Avoid: the composable owns state it shouldn't
@Composable
fun SearchBar() {
    var query by remember { mutableStateOf("") }
    TextField(value = query, onValueChange = { query = it })
}
 
// Prefer: state is hoisted, composable is stateless
@Composable
fun SearchBar(
    query: String,
    onQueryChange: (String) -> Unit,
    modifier: Modifier = Modifier
) {
    TextField(value = query, onValueChange = onQueryChange, modifier = modifier)
}

The stateless version is trivially testable, previewable with any input, and reusable anywhere — a settings screen, a dialog, a full-screen search — without dragging along assumptions about where its state lives. Keep a thin stateful wrapper at the screen level if you need one, and let everything below it be dumb and predictable.

2. Design with slots, not booleans

A common anti-pattern is a component that grows a new Boolean or nullable parameter every time a designer asks for a variant:

@Composable
fun InfoCard(
    title: String,
    showIcon: Boolean,
    iconRes: Int? = null,
    showAction: Boolean = false,
    actionText: String? = null,
    onActionClick: (() -> Unit)? = null
)

Six months in, this function has fifteen parameters and half of them are mutually exclusive in ways nobody's documented. A slot API — composable lambda parameters instead of flags — scales much better:

@Composable
fun InfoCard(
    modifier: Modifier = Modifier,
    leadingIcon: @Composable (() -> Unit)? = null,
    title: @Composable () -> Unit,
    trailingAction: @Composable (() -> Unit)? = null
) {
    Card(modifier) {
        Row(verticalAlignment = Alignment.CenterVertically) {
            leadingIcon?.invoke()
            Box(Modifier.weight(1f)) { title() }
            trailingAction?.invoke()
        }
    }
}

Now callers compose whatever content they need — an icon, a badge, a button, nothing — without the component itself needing to know what "action" or "icon" means. This is the same pattern Scaffold, TopAppBar, and Card use internally, and it's worth copying.

3. Every composable should accept — and pass through — a Modifier

This one's simple but gets skipped constantly: every public composable should take a Modifier = Modifier parameter, apply it to its outermost layout node, and not have a default that fights the caller (like a hardcoded padding the caller can't remove). Skipping this is the single biggest reason people end up wrapping your component in an extra Box just to add margin.

@Composable
fun UserAvatar(
    imageUrl: String,
    modifier: Modifier = Modifier // always present, always applied first
) {
    AsyncImage(
        model = imageUrl,
        contentDescription = null,
        modifier = modifier.clip(CircleShape)
    )
}

4. Keep composables small enough to preview meaningfully

If you can't write a useful @Preview for a composable without mocking half your app's dependencies, it's doing too much. A good litmus test: can you preview it with hardcoded sample data and no ViewModel, repository, or navigation controller in sight?

@Preview
@Composable
private fun InfoCardPreview() {
    InfoCard(
        leadingIcon = { Icon(Icons.Default.Info, null) },
        title = { Text("Battery optimization available") },
        trailingAction = { TextButton(onClick = {}) { Text("View") } }
    )
}

Composables that need real data sources to render are composables that need to be split — pull the data-fetching and business logic up into a stateful wrapper, and leave the presentation piece pure.

5. Avoid duplicate sources of truth

A subtle bug pattern: a composable receives a value via parameter, then also keeps a local remember copy of "the same" value, and the two drift out of sync after a recomposition or process death.

// Bug waiting to happen
@Composable
fun VolumeSlider(initialVolume: Float) {
    var volume by remember { mutableStateOf(initialVolume) }
    // if initialVolume changes upstream, this composable never finds out
}

If a value can change from outside, it needs to be a parameter that's read fresh on every recomposition — not seeded into local state once. Reach for remember(key) if you genuinely need to reset local state when an identity changes, but treat that as the exception, not the default.

6. Let stability do the performance work for you

Compose skips recomposition for composables whose inputs are stable and unchanged — but only if the compiler can actually prove that. Data classes with var properties, or classes holding List/Map (which the compiler treats as unstable by default), silently opt your composable out of that optimization. In practice this means:

• Prefer val and immutable collections (ImmutableList from kotlinx.collections.immutable, or plain List treated as read-only by convention) in state holders that back Compose UI.
• Run the Compose compiler's stability report during code review on performance-sensitive screens — it's often surprising which classes are silently unstable.
• Use @Immutable or @Stable annotations deliberately, not as a blanket fix, once you've confirmed the class actually behaves that way. None of this matters for a static settings screen. It matters a lot for a list of hundreds of IoT devices updating live sensor readings.

The underlying principle

Every one of these rules is really one idea wearing different clothes: a well-designed composable is a pure function of its inputs, and every design decision should make that easier to see, not harder. Hoist the state, expose slots instead of flags, pass the modifier through, keep the function small enough to preview in isolation. Do that consistently across a codebase and the fifteen-parameter God Composable stops happening — not because anyone bans it, but because the alternative is just easier to write.

In this article, you’ll learn how the Lifecycle.repeatOnLifecycle, and Flow.flowWithLifecycle APIs protect you from wasting resources and why they’re a good default to use for flow collection in the UI layer.

Wasting resources It’s recommended to expose the Flow API from lower layers of your app hierarchy regardless of the flow producer implementation details. However, you should also collect them safely.

A cold flow backed by a channel or using operators with buffers such as buffer, conflate, flowOn, or shareIn is not safe to collect with some of the existing APIs such as CoroutineScope.launch, Flow.launchIn, or LifecycleCoroutineScope.launchWhenX, unless you manually cancel the Job that started the coroutine when the activity goes to the background. These APIs will keep the underlying flow producer active while emitting items into the buffer in the background, and thus wasting resources.

Note: A cold flow is a type of flow that executes the producer block of code on-demand when a new subscriber collects.

// Implementation of a cold flow backed by a Channel that sends Location updates
fun FusedLocationProviderClient.locationFlow() = callbackFlow<Location> {
    val callback = object : LocationCallback() {
        override fun onLocationResult(result: LocationResult?) {
            result ?: return
            try { offer(result.lastLocation) } catch(e: Exception) {}
        }
    }
    requestLocationUpdates(createLocationRequest(), callback, Looper.getMainLooper())
        .addOnFailureListener { e ->
            close(e) // in case of exception, close the Flow
        }
    // clean up when Flow collection ends
    awaitClose {
        removeLocationUpdates(callback)
    }
}

Visual diagram

Circling back to the beginning, collecting locationFlow directly from a coroutine started with lifecycleScope.launch was dangerous since the collection keeps happening even when the View is in the background.

repeatOnLifecycle prevents you from wasting resources and app crashes because it stops and restarts the flow collection when the lifecycle moves in and out of the target state.

Comparison with LiveData You might’ve noticed that this API behaves similarly to LiveData, and that’s true! LiveData is aware of Lifecycle, and its restarting behavior makes it ideal for observing streams of data from the UI. And that’s also the case for the Lifecycle.repeatOnLifecycle, and Flow.flowWithLifecycle APIs!

Collecting flows using these APIs is a natural replacement for LiveData in Kotlin-only apps. If you use these APIs for flow collection, LiveData doesn’t offer any benefits over coroutines and flow. Even more, flows are more flexible since they can be collected from any Dispatcher and they can be powered with all its operators. As opposed to LiveData, which has limited operators available and whose values are always observed from the UI thread.

StateFlow support in data binding On a different note, one of the reasons you might be using LiveData is because it’s supported by data binding. Well, so is StateFlow! For more information about StateFlow support in data binding, check out the official documentation.

Use the Lifecycle.repeatOnLifecycle or Flow.flowWithLifecycle APIs to safely collect flows from the UI layer in Android.

Hilt was first released as alpha in June 2020 with the mission of defining a standard way to do DI in your Android apps and since then, we’ve received tons of feedback from developers. That not only improved the library, but also, it let us know that we’re working on the right problems.

Instead of creating dependency graphs by hand, and manually injecting and passing around types where needed, Hilt automatically generates all that code for you at compile time by means of annotations. Hilt can help you get the most out of DI best practices in your app by doing the hard work and generating all that boilerplate you would’ve needed to write otherwise. Also, as it’s fully integrated with Android, Hilt manages the lifecycle of the dependency graphs associated with the Android framework classes automatically for you.

Let’s see Hilt in action with a quick example! After setting Hilt up, using it in your project from scratch to inject a ViewModel in an Activity is as easy as adding few annotations to your code as follows:

@HiltAndroidApp // Setup Hilt in your app
class MyApplication : Application() { ... }

// Make Hilt aware of this ViewModel
@HiltViewModel
class LoginViewModel @Inject constructor(
    private val savedStateHandle: SavedStateHandle,
    /* ... Other dependencies Hilt takes care of ... */
) : ViewModel() { ... }


// Make the activity use the right ViewModel factory and
// inject other dependencies
@AndroidEntryPoint 
class LoginActivity : AppCompatActivity() {

    private val loginViewModel: LoginViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // loginViewModel is ready to be used
    }
}

Apart from what’s mentioned above, why should you use Hilt in your Android app?

Simpler than Dagger Hilt is built on top of the popular DI library Dagger so benefits from the compile time correctness, runtime performance, scalability, and Android Studio support that Dagger provides. Some Dagger annotations, such as @Inject to tell Dagger and Hilt how to provide an instance of a type, are often used in Hilt. But Hilt is simpler than Dagger!

“I highly recommend leveraging Dagger for dependency injection in Android applications. However, pure vanilla Dagger can lead to too much room for creativity. When that gets mixed with the complexity of the various lifecycle-aware components that are part of Android development, there’s plenty of room for pitfalls such as memory leaks: for example, accidentally passing in Activity-scoped dependencies into ViewModels. Hilt being opinionated and designed specifically for Android helps you avoid some of the pitfalls when using vanilla Dagger.” — Marcelo Hernandez, Staff Software Engineer, Tinder

If you’re already using Dagger in your app and want to migrate to Hilt… fear not! Dagger and Hilt can coexist together, apps can be migrated on an as-needed basis.

Less boilerplate Hilt is opinionated — this means that it makes decisions for you so that you have less code to write. Hilt defines standard components, or dependency graphs, fully integrated with Android framework classes such as Application, activities, fragments, and views. As well as scope annotations to scope instances of types to those components.

“Hilt automatically generates the test application and test component via @HiltAndroidTest. We were able to remove between 20% and 40% of boilerplate wire up test code after migrating to Hilt!” — Jusun Lee, Software Engineer, YouTube

“We are only scratching the surface in terms of migrating to Hilt. However, in one of the modules we migrated to Hilt, we saw +78/-182 in terms of lines changed for this library.” — Marcelo Hernandez, Staff Software Engineer, Tinder

Designed for Android As opposed to Dagger that is a dependency injection solution for the Java programming language applications, Hilt solely works in Android apps. Some annotations such as

@HiltAndroidApp, @AndroidEntryPoint, or @HiltViewModel are specific to Hilt and define an opinionated way to do DI on Android.

“Hilt finally offers built-in Android lifecycle aware Dagger components. With Hilt, we can solely focus on Dagger @Modules without having to worry about Components, Subcomponents, the Component provider pattern, and so on.” — Marcelo Hernandez, Staff Software Engineer, Tinder

Standardization of components and bindings For those that know about Dagger, Hilt simplifies the dependency graph by using a monolithic component system to generate less code at compile time.

“With Hilt’s monolithic component system, binding definitions are provided once and shared across all classes that use that component. This is a big win as previously, YouTube used a polylithic component system where modules were manually wired-up into custom components and there were many duplicate binding definitions.” — Jusun Lee, Software Engineer, YouTube

“As our Gradle modules separation allows for feature development in isolation, it became easy to be too creative when using Dagger. We’ve found that migrating those modules over to Hilt has actually exposed flaws in which we were inadvertently violating the separation of concerns.” — Marcelo Hernandez, Staff Software Engineer, Tinder

To make our findings as easy to follow as possible, we needed a sample that has a familiar business case and isn’t too complicated. And… who doesn’t know about TODO apps? We chose Architecture Blueprints! Historically, Blueprints served as an experimental playground for architecture choices. What a great fit for this as well!

The patterns we want to experiment with are obviously affected by the different APIs available nowadays. The new kids in town are Jetpack Compose’s State APIs! As Compose seamlessly works with any Unidirectional Data Flow pattern, we’ll use Compose to render UI to make a fair comparison.

This blog post tells the story of how the team migrated Architecture Blueprints to Jetpack Compose. As LiveData is also considered an alternative in our experiments, we left the sample as it was at the time of the migration. In this refactoring, the ViewModel classes and the data layer were left untouched.

⚠️ The architecture used in this LiveData-based codebase doesn’t fully follow the latest architecture best practices. In particular, LiveData shouldn’t be used in the data or domain layers — Flows and coroutines should be used instead.

Now that the context is clear, let’s dive in on how we approached refactoring Blueprints to Jetpack Compose. You can check out the full code on the main branch.

The goal of a gradual migration is to ease code reviews and maintain a shippable product throughout the migration. The migration plan involved three steps:

Migrate the content of each screen to Compose. Each screen could be individually migrated to Compose, including their UI tests. Fragments then become the container/host of each migrated screen.

Migrate the app to Navigation Compose — which removes all Fragments from the project — and migrate the Activity UI logic to root composables. End-to-end tests are also migrated at this point.

Remove View system dependencies.