Seminar Cuttlefish – AOSP-Builds und System-Images

Cuttlefish entfaltet seinen größten Nutzen, wenn eigene Android-Builds reproduzierbar erzeugt, eindeutig versioniert und mit passenden Hostartefakten gestartet werden. Das Seminar führt von der Buildumgebung über Produktziele und Partitionen bis zur kontrollierten Bereitstellung eigener Images.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik
• Einordnung

Zielsetzung

• Eine reproduzierbare AOSP-Arbeitsumgebung für Cuttlefish aufbauen
• Produktziele, Lunch-Kombinationen und Hostpakete korrekt auswählen
• System-, Vendor-, Boot- und weitere Images fachlich einordnen und erzeugen
• Eigene Builds starten, iterativ aktualisieren, prüfen und als versioniertes Artefaktset bereitstellen

Zielgruppe

AOSP-Entwicklung, Android-Plattformentwicklung, Build Engineering, Release Engineering, DevOps und technische Integration.

Voraussetzungen

Sichere Linux-Administration, Git- und Repo-Grundkenntnisse, Android-Architekturverständnis sowie ausreichend Buildressourcen.

Seminarinhalte

1. Schritt 1: Buildstrategie und Branch festlegen

   Releasezweck, Zielarchitektur, Produktziel, Quellbranch und Artefaktversion werden gemeinsam definiert. Die Entscheidung wird so dokumentiert, dass Hostpaket und Geräte-Images aus demselben Buildkontext stammen.

2. Schritt 2: Quellen und Buildumgebung vorbereiten

   Repo-Manifest, Quellsynchronisation, Speicherbedarf, Compilerumgebung und Caches werden geprüft. Wiederanlauf, Teilbuilds und saubere Buildzustände werden voneinander abgegrenzt.

3. Schritt 3: Cuttlefish-Produktziel konfigurieren

   Geeignete Produkt- und Buildvarianten werden ausgewählt. Board- und Produktkonfiguration, Architektur, Debuggability und enthaltene Module werden nachvollziehbar geprüft.

4. Schritt 4: Hostwerkzeuge und Geräte-Images bauen

   Cuttlefish-Hostpakete und Android-Images werden erzeugt und als zusammengehöriges Set abgelegt. Buildprotokolle, Ausgabeverzeichnisse und relevante Artefakte werden systematisch kontrolliert.

5. Schritt 5: Partitionen und Imagebeziehungen analysieren

   Boot, Vendor Boot, System, Vendor, Product, Userdata und dynamische Partitionen werden funktional eingeordnet. Auswirkungen von Änderungen auf Start, Kompatibilität und Updatepfade werden bewertet.

6. Schritt 6: Eigenen Build starten und aktualisieren

   Der Build wird mit passender CVD-Konfiguration gestartet. Gezielte Änderungen werden neu gebaut, Images ausgetauscht und mit kontrollierten Neustart- oder Bereinigungsstrategien validiert.

7. Schritt 7: Buildfehler diagnostizieren

   Abhängigkeiten, Ninja-Fehler, fehlende Artefakte, Speicherengpässe und inkonsistente Ausgabeverzeichnisse werden mit einem festen Diagnoseablauf bearbeitet.

8. Schritt 8: Artefakte veröffentlichen und reproduzieren

   Versionsschema, Prüfsummen, Manifeststand, Konfiguration und Startparameter werden zu einem auslieferbaren Artefaktpaket zusammengeführt. Ein zweiter Aufbau dient als Reproduzierbarkeitsprüfung.

Praxisübungen

• Ein vollständiges Cuttlefish-Ziel mit Hostpaket und Images aus einem definierten Branch bauen
• Eine kleine Frameworkänderung erstellen, gezielt neu bauen und auf einer bestehenden Testinstanz validieren
• Ein versioniertes Artefaktset mit Manifeststand, Konfiguration, Prüfsummen und Startprüfung erzeugen

Methodik

Die vier Tage folgen einem realen Build-Lebenszyklus: Planung, Quellaufbau, Vollbuild, inkrementelle Änderung, Imageanalyse und Veröffentlichung. Fehler werden nicht nur behoben, sondern als wiederholbare Buildkontrollen dokumentiert.

Einordnung

Vier Tage sind erforderlich, weil vollständige Builds, inkrementelle Änderungen, Partitionsthemen, Fehleranalyse und reproduzierbare Artefaktbereitstellung jeweils eigenständige Arbeitsphasen mit längeren Laufzeiten bilden.