Great question—let’s break this down clearly based on AOSP’s official development model:

1. Does the public AOSP main branch include future version features? #

Yes, but only partially. Here’s the context:

• Google builds full future Android versions (like the "P" build you’re seeing) in private internal branches that aren’t accessible to external developers.
• The public main branch you sync gets periodic merges of stable, ready-to-publicize code from those private future-version branches. So you’ll find early implementations of future APIs, framework changes, and core features that Google has finalized enough to share externally.
• The build info you shared confirms this:

  PLATFORM_VERSION_CODENAME=P
  PLATFORM_VERSION=P
  TARGET_PRODUCT=aosp_x86_64
  TARGET_BUILD_VARIANT=eng
  TARGET_BUILD_TYPE=release
  TARGET_ARCH=x86_64
  TARGET_ARCH_VARIANT=x86_64
  TARGET_2ND_ARCH=x86
  TARGET_2ND_ARCH_VARIANT=x86_64
  HOST_ARCH=x86_64
  HOST_2ND_ARCH=x86
  HOST_OS=darwin
  HOST_OS_EXTRA=Darwin-17.3.0-x86_64-10.13.2
  HOST_BUILD_TYPE=release
  BUILD_ID=OC-DR1
  OUT_DIR=out
  

  This means the public main branch is seeded with the foundational code for version P, but not all the in-progress, unpolished features still being worked on in Google’s private branches.

2. What’s the specific role of the AOSP main branch? #

Think of it as the "public hub" for AOSP development:

• It’s the upstream source for all public Android releases (stable, beta, and Go editions). Every stable branch (like Android 14, 13) is forked from the main branch at a specific point in time.
• It acts as a bridge between Google’s internal private development and the external developer community. Only features that are mature, tested, and ready for external feedback make their way into the public main branch.
• It lets external developers and OEMs start early adaptation work for future Android versions. Even without full access to private branches, you can build against the main branch to test compatibility with upcoming API changes.
• It’s the primary branch for external contributions: any patches or improvements from the community are submitted to the main branch first, then merged into relevant stable branches as needed.

3. How does this align with the official code lines diagram? #

The official code lines model splits development into private and public tracks, and the main branch fits right in:

• Google’s private code lines are where full future versions (like P) are built from scratch—this is the closed, internal phase where most new features are designed, implemented, and tested.
• The public main branch is the "release valve" for these private lines. When features reach a stable state, they’re merged from the private future-version branch into the public main branch.
• From the diagram’s perspective, the main branch sits at the center of the public code lines: it feeds into all active stable branches (via backports) and receives updates from Google’s private future development branches. The "P" codename you see signals that the main branch is now being seeded with code from the private P development line, ahead of its eventual public release.

内容的提问来源于stack exchange，提问作者darklord