fix: make custom boot animation survive OTA repacking

[0cwa]

Problem

The custom boot-animation selection can validate and reach the patch helper but still disappear from the installed OTA.

The local adapter currently writes directly into ext_fs["system"].tree. The pinned helper/AFSR path is metadata-driven: new files need to be created through the helper's ExtFs.mkdir() / ExtFs.open() API so filesystem metadata and SELinux labels are updated alongside the unpacked tree. GrapheneOS does not need to already contain the exact target file, so a direct tree-only addition can be omitted when the image is repacked.

There are two adjacent Android compatibility issues:

• current Android checks the product boot-animation location before the system fallback;
• BootAnimation only accepts stored (uncompressed) frame entries, while our payload validator intentionally permits safe DEFLATE input.

Fix

Keep the soft-fork boundary in ModOS; do not modify or fork the pinned helper.

• Request the standard product ext image from the existing helper API.
• Install through ExtFs.mkdir() and ExtFs.open(), so AFSR metadata/tree/labels stay synchronized.
• Install the runtime payload at both standard product targets:
  • /product/media/bootanimation.zip
  • /product/media/bootanimation-dark.zip
• Canonicalize the already-validated local archive into a deterministic ZIP with stored entries before injection, so Android can consume frame members even when the source ZIP used DEFLATE.
• Add a regression test whose fake filesystem deliberately fails if code reaches through .tree, and verify both product targets receive the stored runtime archive.

Soft-fork scope

This remains a thin ModOS-owned local adapter registered into the pinned helper at build time. No AVBRoot changes and no permanent fork-only adapter changes in my-avbroot-setup.

Related branch audit

Active PRs #96 and #97 both still carry the old tree-direct boot-animation adapter. The same focused fix is being propagated to their head branches so they do not reintroduce the bug if merged later.

PR #96's updater-removal adapter was also reviewed for the same AFSR metadata hazard; it explicitly preflights tree/metadata agreement and removes both the tree file and metadata entry, so no correction is needed there.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: a4969e4f-3811-4c99-9f09-6c31d9c1f806

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}