کد نام ها، برچسب ها و شماره های ساخت

نسخه‌های توسعه اندروید در خانواده‌هایی با نام‌های رمز الفبایی سازماندهی می‌شوند.

تگ‌ها و ساختارهای کد منبع

با شروع از Donut، لیست دقیق برچسب‌ها و نسخه‌های ساخته شده در جدول زیر آمده است. شناسه ساخت، اطلاعاتی مانند نسخه پلتفرم، شاخه کد و تاریخ انشعاب یا همگام‌سازی نسخه منتشر شده با شاخه توسعه را ارائه می‌دهد.

Build ID definitions

In Android 8.0.0 (Oreo) and higher builds are identified with the build ID format PVBB.YYMMDD.bbb[.Cn] , where:

• P represents the first letter of the codename of the platform release, for example, O is Oreo. For Android 10 and later codenames, the letter equivalent is used, such as Q for Android 10 and R for Android 11.
• V represents a supported vertical. By convention, P represents the primary platform branch.
• BB is an alphanumeric code that allows Google to identify the exact code branch the build was made from.
• YYMMDD identifies the date when the release is branched from or synced with the development branch. It's not always the exact date at which a build was made as it's common for minor variations added to an existing build to re-use the same date code as the existing build.
• bbb identifies individual versions related to the same date code, sequentially starting with 001 .
• Cn is an optional, alphanumeric that identifies a hotfix on top of an existing PVBB.YYMMDD.bbb build, starting from A1 .

Android 7.00 and older releases use a different, shorter build ID (for example, FRF85B ) where:

• The first letter is the codename of the release family, for example, F is Froyo.
• The second letter is a branch code that allows Google to identify the exact code branch the build was made from. By convention, R is the primary release branch.
• The third letter and following two numbers are a date code. The letter counts quarters ( A is Q1 2009, F is Q2 2010, and so on). The two numbers count days within the quarter ( F85 is June 24, 2010). The date code isn't always the exact date at which a build was made as it's common for minor variations added to an existing build to re-use the same date code as the existing build.
• The last letter identifies individual versions related to the same date code, sequentially starting with A (which is implicit and usually omitted for brevity).

Security updates use purely numerical Build ID (for example, 7786871 ) and are part of the source code releases based on the backport branches. You can apply these security updates to your previous Android versions.

Finally, the branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, and kitkat-dev represent development branches that don't exactly match configurations tested by Google. As such, these branches might contain a variety of changes in addition to the official tagged releases and might not be as thoroughly tested.

Differentiate between releases

To differentiate between releases, you can get a list of changes associated with each project by issuing the following command and passing it the two branch tags:

repo forall -pc 'git log --no-merges --oneline branch-1..branch-2'

برای مثال:

repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1'

To send the output to a text file:

  repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1' > /tmp/android-4.4.2_r2-android-4.4.2_r1-diff.txt

Honeycomb GPL modules

For Honeycomb, the entire platform source code isn't available. However, the parts of Honeycomb licensed under the GPL and LGPL are available under the following tags.

No manifest contains exactly these modules, but some manifests allow building those components. The following commands work for 3.0_r1.1:

repo init -b main -m base-for-3.0-gpl.xml
repo sync
repo forall -c git checkout android-3.0_r1.1

To use another version, change the git checkout parameter and (if necessary) the -m parameter in repo init . The git checkout command outputs an error for any non-GPL projects where it can't find the tag.

Device codenames

The following table lists the device code names for Google devices. You can use these code names to form build target strings used with the lunch command: