Seminar Cuttlefish – Custom Devices und Gerätekonfiguration

Standardgeräte reichen für viele Produkt- und Testanforderungen nicht aus. Eigene Cuttlefish-Geräte verbinden AOSP-Produktkonfiguration, Hardwareeigenschaften, Ressourcenprofile, Displays und Startparameter zu einer versionierbaren virtuellen Zielplattform.

Inhaltsübersicht

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

Zielsetzung

• Eigene virtuelle Gerätemodelle fachlich und technisch spezifizieren
• Produkt- und Boardkonfiguration sauber von Laufzeitparametern trennen
• Ressourcen, Displays, Eigenschaften und Startkomponenten deklarativ abbilden
• Custom Devices bauen, versionieren, validieren und für Tests bereitstellen

Zielgruppe

AOSP-Entwicklung, Android-Systemarchitektur, Geräteintegration, Testplattform-Entwicklung und technische Projektleitung.

Voraussetzungen

AOSP-Buildkenntnisse, Android-Produkt- und Boardgrundlagen sowie sichere Cuttlefish-Bedienung.

Seminarinhalte

1. Schritt 1: Geräteanforderungen modellieren

   Formfaktor, Architektur, CPU, RAM, Datenträger, Displays, Grafik, Netzwerk und besondere Android-Eigenschaften werden als prüfbare Gerätespezifikation erfasst.

2. Schritt 2: Basistarget und Vererbung auswählen

   Ein geeignetes Cuttlefish-Produktziel wird als Ausgangspunkt gewählt. Vererbte Makefiles, Produktpakete und Boardvorgaben werden transparent gemacht, bevor Änderungen beginnen.

3. Schritt 3: Produktkonfiguration erweitern

   Eigene Produktdateien, Pakete, Eigenschaften, Overlays und Buildvarianten werden schrittweise ergänzt. Änderungen bleiben klein, versionierbar und testbar.

4. Schritt 4: Kanonische Gerätekonfiguration erstellen

   Ressourcen- und Displaywerte werden in einer deklarativen Konfiguration zusammengeführt. Syntax, zulässige Werte, Standardannahmen und Namenskonventionen werden validiert.

5. Schritt 5: Build- und Laufzeitkomponenten verbinden

   Hostpaket, Android-Images, Produktziel und Gerätekonfiguration werden als konsistentes Set gestartet. Abweichungen zwischen Buildzeit und Laufzeit werden gezielt erkannt.

6. Schritt 6: Gerätevarianten ableiten

   Aus einer Basis entstehen Varianten für unterschiedliche Displays, Speichergrößen, Grafikmodi oder Testrollen. Gemeinsame und abweichende Parameter werden so strukturiert, dass keine unkontrollierten Kopien entstehen.

7. Schritt 7: Kompatibilität und Verhalten prüfen

   Boot, ADB, zentrale Dienste, Display, Netzwerk, Speicher und definierte Produktmerkmale werden mit Smoke- und Regressionstests abgesichert.

8. Schritt 8: Konfiguration veröffentlichen

   Quellstand, Artefakte, Konfigurationsschema, Versionsregeln und Testnachweis werden zu einem freigabefähigen Gerätepäckchen verbunden.

Praxisübungen

• Ein eigenes Gerätemodell aus einer Anforderungenliste ableiten und als deklarative Konfiguration umsetzen
• Zwei Varianten mit unterschiedlichen Ressourcen- und Displayprofilen aus einer gemeinsamen Basis erzeugen
• Ein Custom Device bauen, starten und über definierte Smoke-Tests freigeben

Methodik

Anforderungen werden konsequent in Konfiguration und Prüfungen übersetzt. Jede Änderung durchläuft Spezifikation, Build, Start, Messung und versionierte Freigabe.

Einordnung

Drei Tage sind erforderlich, weil Geräteentwurf, AOSP-Produktanpassung, deklarative Laufzeitkonfiguration, Variantenbildung und Validierung mehrere aufeinander aufbauende Praxisphasen bilden.