1 of 20

Accelerating Android Releases:

An Unofficial Guide to Trunk Stable

FOSDEM 2025, Serban Constantinescu

2 of 20

About me ( serban@source.dev )

  • Worked on Android for 13 years
    • SWE contributed to 64-bit Android, PM for Arm Memory Tagging @ Arm
    • PM for Android Regulation, Android Runtime, Android Virtualization, etc. @ Google Android
  • In 2024 left Google to start Source.dev
    • We are building an AI-native DevOps platform for device codebases - to make developing and maintaining software for devices simple and cost effective, starting with Android
    • We are hiring!
  • An unofficial guide to Trunk Stable
    • ⚠️While I was deeply involved with Android’s Longevity please take this as an outsider’s view

2

FOSDEM 2025

3 of 20

What is Trunk Stable? ( A new process to streamline dev and improve quality )

A new upstream Android development process where all releases are cut from

a single main development branch that must remain stable at all times.

It requires all new features to be flagged so that they can,

on a case-by-case basis, be included or excluded from a release.

3

FOSDEM 2025

4 of 20

Background: Old development model ( features, timeline )

4

Android X

is released

Android X +1

code freeze

Android X +1

development starts

Android X +1

is released

Timeline

FOSDEM 2025

5 of 20

Background: Old development model ( features, timeline )

Android X

is released

Android X +1

code freeze

Android X +1

development starts

Android X +1

is released

Many features

Features

Merged into the release branch

Timeline

Some features might have benefited from a longer development timeline

FOSDEM 2025

6 of 20

Background: Old development model ( features, timeline )

Android X

is released

Android X +1

code freeze

Android X +1

development starts

Android X +1

is released

Many features

Features

Merged into the release branch

Timeline

Some features might have benefited from a longer development timeline

Quality

🔥Stabilizing the codebase after release

🔥Quality drop during code freeze and early release

FOSDEM 2025

7 of 20

Background: Old development model ( features, timeline )

Android X

is released

Android X +1

code freeze

Android X +1

development starts

Android X +1

is released

Many features

✅Features

Merged into the release branch

✅Timeline

Some features might have benefited from a longer development timeline

❌Quality

🔥Stabilizing the codebase after release

🔥Quality drop during code freeze and early release

FOSDEM 2025

8 of 20

The new development model ( features, quality )

8

Timeline

Q1 Release

Q2 Major SDK Release

Q3 Release

Q4 Minor SDK

Release

Features only

APIs, features,

behaviour changes

APIs,

features

Features only

FOSDEM 2025

9 of 20

The new development model ( features, quality )

9

Timeline

Q1 Release

Q2 Major SDK Release

Q3 Release

Q4 Minor SDK

Release

Features

🏁 features

only

🏁 features

only

🏁 features

only

🏁 features

only

Unstable features remain flagged OFF until ready for release

Features only

APIs, features,

behaviour changes

APIs,

features

Features only

FOSDEM 2025

10 of 20

The new development model ( features, quality )

10

Timeline

Q1 Release

Q2 Major SDK Release

Q3 Release

Q4 Minor SDK

Release

Features

🏁 features

only

🏁 features

only

🏁 features

only

🏁 features

only

Unstable features remain flagged OFF until ready for release

Quality

✔️ Stable quality most times!

Features only

APIs, features,

behaviour changes

APIs,

features

Features only

FOSDEM 2025

11 of 20

The new development model ( features, quality )

11

☑️Timeline

Q1 Release

Q2 Major SDK Release

Q3 Release

Q4 Minor SDK

Release

✅Features

🏁 features

only

🏁 features

only

🏁 features

only

🏁 features

only

Unstable features remain flagged OFF until ready for release

✅Quality

✔️ Stable quality most times!

Features only

APIs, features,

behaviour changes

APIs,

features

Features only

FOSDEM 2025

12 of 20

Old vs. New development model ( features, quality, timeline - choose two )

12

Old development model

features, timeline

​

  • 🌿Branch-based development
  • Yearly release cycle
  • Hard to maintain codebase quality
  • One major SDK release per year in Q3

New development model - Trunk Stable features, quality

​

  • 🏁Flag-based development
  • Quarterly release cycle
  • Easier to maintain codebase quality
  • Two SDK releases per year with major in Q2

FOSDEM 2025

13 of 20

Old vs. New development model ( features, quality, timeline - choose two )

13

Downstream OS forks ( yearly )

  • Yearly rebase and testing cycle
  • Difficult to identify upstream issues
  • Long time required to stabilize and release

🆕 Downstream OS forks ( continuous )

  • Can rebase and test continuously
  • Can identify upstream issues early
  • Can reduce the time to update the codebase

Old development model

features, timeline

​

  • 🌿Branch-based development
  • Yearly release cycle
  • Hard to maintain codebase quality
  • One major SDK release per year in Q3

New development model - Trunk Stable features, quality

​

  • 🏁Flag-based development
  • Quarterly release cycle
  • Easier to maintain codebase quality
  • Two SDK releases per year with major in Q2

FOSDEM 2025

14 of 20

When to use flag based development? ( always! )

​

  • Most modern large-scale software codebases use flag-based development!
  • Flags separate experiments and unreleased code during testing and release
  • All changes that can lead to codebase instability should use flags!
    • Use flags for new features, complex bugs, API changes
  • All changes that can’t lead to codebase instability can choose not to use flags
    • Use for simple bug fixes, comments or where a flag already exists

14

FOSDEM 2025

15 of 20

What are the types of flags I can use? ( aconfig or build flags )

Run-time controlled flags (AConfig)

  • Use for C, C++, Java, Rust - runtime checks if flag is set or not
  • Can be read-write - flag value can be changed across reboots ( use for development )
    • ⇒ Can be server-controlled ( e.g. Dogfood )
  • Can be read-only - flag value can’t be changed ( use for release )
    • ⇒ Compilers can determine flag value is constant and optimize code paths

Build-time controlled flags

  • Use for prebuilt code, low-level firmware, or build system changes

​

More info here: https://source.android.com/docs/setup/build/feature-flagging

15

FOSDEM 2025

16 of 20

What are the release flavours? (aosp_current, runk_staging, releases)

$ source ./build/envsetup.sh

$ lunch aosp_cf_x86_64_phone-trunk_staging-eng

$ list_releases

aosp_current # mapped (inherits) from the latest release ap4a

ap2a # release

ap3a # release

ap4a # release

trunk_staging # a development release configuration

next # google internal, next release configuration

​

$ cat out/soong/release-config/build_flags_product.json

{

"flags": [

{

"flag_declaration": {

"name": "RELEASE_ACONFIG_FLAG_DEFAULT_PERMISSION",

"namespace": "android_UNKNOWN",

"description": "The default permission for all flags",

16

FOSDEM 2025

17 of 20

What are the aflags values? ( aconfig flags are reboot-stable )

$ adb shell aflags list

# flag name default value type namespace

android.adpt.enable_adaptive_auth enabled - default read-write system

android.adpt.report_biometric_auth enabled - default read-write system

android.app.admin.flags.allow_querying enabled - default read-only system

android.app.admin.flags.assist_content disabled - default read-write vendor

17

FOSDEM 2025

18 of 20

What is the lifecycle of a feature flag? ( do not skip stages )

18

Add feature flag infrastructure

…

1

2

Start feature development behind feature flag

3

Enable feature locally for testing

4

Enable feature Dogfood-wide for testing

Enable feature for next release

5

🆕Automatically disable feature if any issues

6

FOSDEM 2025

19 of 20

When do I get new features? ( IANAL, but EU EcoDesign regulation might help )

19

Smartphones and Tablets placed on the EU market starting 20th June 2025 MUST comply with:

  • Security Updates: Available within 4 months of the public source code release
  • Feature/OS Updates: Released within 6 months of the public source code release
  • Support Duration: Provide updates for at least 5 years after the end of placement of a device
  • Performance Assurance: Ensure updates maintain the device’s original performance levels

​

More info here: https://energy-efficient-products.ec.europa.eu/product-list/smartphones-and-tablets_en

FOSDEM 2025

20 of 20

Thanks!

​

Want to work on an exciting project (with ex-Google Android team)?

We are hiring Android OS engineers!

Email us at: serban@source.dev

​

20