kernel: add a pinned manifest alongside the branch-tracking one - #1
Open
yuichi-kusakabe wants to merge 1 commit into
Open
Conversation
The manifest this branch ships names its projects by branch -- main-kernel-2026, android17-6.18, gbl-android17, u-boot-android17 -- so `repo sync` against one manifest revision produces a different tree on a different day. That is what a development branch wants. A product build that has to be reproducible from a recorded revision needs the opposite. Rather than change how default.xml works, this adds a second entry point next to it. Nothing existing is touched: default.xml, common-android17-6.18.xml and common-android17-6.18-override.xml are unmodified, so `repo init -m default.xml` (and the default) behave exactly as before. default.xml unchanged -- tracks branches, for development pinned-common-android17-6.18.xml new -- every project pinned, for products The new file is the output of `repo manifest -r` from a sync that completed and produced a booting guest kernel: 59 projects, each with an explicit revision, with upstream= and dest-branch= preserved so `repo sync` still knows which branch a project tracks and `repo start` still works. It is self-contained (remotes, default, all projects), so `repo init -m pinned-common-android17-6.18.xml` works on its own. The XenVM xen-virtual-device overlay from the -override.xml file is folded in, because `repo manifest -r` resolves includes and emits one flat list. Two entries in it still name a branch and both are inert: <default revision="main-kernel-2026"> is never consulted because all 59 projects carry their own revision, and the superproject entry is not used by a plain `repo sync`. xen-troops pins the same way on common-android17-6.18-xenvm-trout-ih-main (58 of 58 projects carry a SHA there), so the arrangement is not new to this family of manifests -- only its being optional here is. Built and run: the GKI 6.18 kernel built from this manifest boots the AAOS 17 guest under Xen as the Android domain of the AGL SoDeV cockpit. Verified on 2026-08-18 in all four configurations of that demo (Raspberry Pi 4 and Pi 5, each with a Zephyr and a thin-Linux control domain): the guest reports 6.18.32-android17-5, reaches sys.boot_completed=1, and its virtio devices come up (the xen-virtual-device overlay in this manifest is what provides them). Signed-off-by: Yuichi Kusakabe <yuichi_kusakabe@jp.honda>
yuichi-kusakabe
added a commit
to automotive-grade-linux/sodev-demo-workspace-rpi
that referenced
this pull request
Sep 4, 2026
The AAOS guest kernel component asks its manifest repository for pinned-common-android17-6.18.xml, an entry point that adds every project's SHA alongside the branch-tracking manifest, so that a workspace revision resolves to one tree instead of whatever the tracked branches point at that day. That entry point is not in the upstream branch yet: yhamamachi/android_kernel_manifest#1 (open) So both boards point at a fork branch that is upstream's own android-17-xenvm-sh-main plus exactly that one commit, and nothing else: yuichi-kusakabe/android_kernel_manifest @ android-17-xenvm-rpi-pinned. Without it `repo init -m pinned-common-android17-6.18.xml` fails on a manifest that has no such file, so this is what makes DomA fetchable, not a preference. WHEN THE PULL REQUEST LANDS: revert this commit and bump the two rev lines it restores to the upstream branch's new head. The revert is why this is a commit of its own -- the AOSP-side pin in the next commit is a separate decision with a separate lifetime, and lumping them together would mean this one could not be undone without undoing that one too. The branch is never force-pushed and the fork stays public while any yaml here names that revision. Assisted-by: Claude Code:claude-opus-5[1m] Signed-off-by: Yuichi Kusakabe <yuichi_kusakabe@jp.honda>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Add
pinned-common-android17-6.18.xmlas a second entry point, next todefault.xml.Nothing existing is modified.
Why
The manifest this branch ships names its projects by branch (
main-kernel-2026,android17-6.18,gbl-android17,u-boot-android17), sorepo syncagainst one manifestrevision produces a different tree on a different day. That is what a development branch
wants. A product build that has to be reproducible from a recorded revision needs the
opposite.
Rather than change how
default.xmlworks, this adds an alternative thatrepo init -mcan select explicitly, so both workflows are available from the same branch.
What the new file is
repo manifest -rfrom a sync that completed and produced a booting guestkernel: 59 projects, each with an explicit revision.
upstream=anddest-branch=are preserved, sorepo syncstill knows which branch aproject tracks and
repo startstill works.<include>), sorepo init -m pinned-common-android17-6.18.xmlworks on its own.xen-virtual-deviceoverlay fromcommon-android17-6.18-override.xmlis foldedin, because
repo manifest -rresolves includes and emits one flat list. Its revision isidentical to the one the override file pins (
e016d45a).Reconciles with what this branch already has: 58 projects in
common-android17-6.18.xml+ 1 overlay = 59.Notes for review
<default revision="main-kernel-2026">is never consulted because all 59 projects carrytheir own revision, and the
<superproject>entry is not used by a plainrepo sync.They are kept because they are what
repo manifest -remits.default.xml,common-android17-6.18.xmlandcommon-android17-6.18-override.xmlarebyte-identical to before, so
repo init -m default.xml(and the default) behaveexactly as they do today.
common-android17-6.18-xenvm-trout-ih-main(58 of 58projects carry a SHA there), so the arrangement is not new to this family of manifests —
only its being optional here is.
Verification
The GKI 6.18 kernel built from this manifest boots the AAOS 17 guest under Xen as the
Android domain of the AGL SoDeV cockpit. Verified on 2026-08-18 in all four
configurations of that demo (Raspberry Pi 4 and Pi 5, each with a Zephyr and a thin-Linux
control domain): the guest reports
6.18.32-android17-5, reachessys.boot_completed=1, and its virtio devices come up — thexen-virtual-deviceoverlayin this manifest is what provides them.
Context
This is one of two changes needed to build the XenVM guest with Android 17 for the AGL
SoDeV Raspberry Pi cockpit; the other is in
android_manifest(Mesa pinned at 25.3.6,which the Android 17 toolchain needs). Both are submitted upstream rather than carried
downstream, because the Pi 5 build has to be the same binary the R-Car V4H demo builds.