Hinzufügen eines neuen Geräts

Verwenden Sie die Informationen auf dieser Seite, um die Makefiles für Ihr Gerät und Produkt zu erstellen.

Jedes neue Android-Modul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierzeit und Verpackungsanweisungen zu leiten. Android nutzt die Soong Build - System . Siehe Gebäude Android für weitere Informationen über das Android - Build - System.

Build-Layer verstehen

Die Build-Hierarchie umfasst die Abstraktionsschichten, die dem physischen Aufbau eines Geräts entsprechen. Diese Schichten werden in der folgenden Tabelle beschrieben. Jede Schicht bezieht sich auf die darüber liegende in einer Eins-zu-Viele-Beziehung. Zum Beispiel kann eine Architektur mehr als ein Board haben und jedes Board kann mehr als ein Produkt haben. Sie können ein Element in einer bestimmten Ebene als Spezialisierung eines Elements in derselben Ebene definieren, wodurch das Kopieren entfällt und die Wartung vereinfacht wird.

Schicht Beispiel Beschreibung
Produkt myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk Die Produktschicht definiert die Funktionsspezifikation eines Versandprodukts, wie die zu erstellenden Module, die unterstützten Gebietsschemas und die Konfiguration für verschiedene Gebietsschemas. Mit anderen Worten, ist dies der Name des Gesamtproduktes. Produktspezifische Variablen werden in Produktdefinitions-Makefiles definiert. Ein Produkt kann von anderen Produktdefinitionen erben, was die Wartung vereinfacht. Eine übliche Methode besteht darin, ein Basisprodukt zu erstellen, das Funktionen enthält, die für alle Produkte gelten, und dann Produktvarianten basierend auf diesem Basisprodukt zu erstellen. Beispielsweise können zwei Produkte, die sich nur durch ihre Funkgeräte (CDMA versus GSM) unterscheiden, von demselben Basisprodukt erben, das kein Funkgerät definiert.
Board/Gerät Marlin, Blueline, Koralle Die Platinen-/Geräteschicht stellt die physikalische Kunststoffschicht auf dem Gerät dar (d. h. das industrielle Design des Geräts). Diese Ebene stellt auch die bloßen Schemata eines Produkts dar. Dazu gehören die Peripherie auf dem Board und deren Konfiguration. Die verwendeten Namen sind lediglich Codes für verschiedene Board-/Gerätekonfigurationen.
Bogen Arm, x86, Arm64, x86_64 Die Architekturschicht beschreibt die Prozessorkonfiguration und die binäre Anwendungsschnittstelle (ABI), die auf dem Board ausgeführt wird.

Build-Varianten verwenden

Beim Erstellen für ein bestimmtes Produkt ist es nützlich, geringfügige Abweichungen vom endgültigen Release-Build zu haben. In einer Moduldefinition kann das Modul - Tags mit angeben LOCAL_MODULE_TAGS , die einen oder mehrere Werte sein können optional (Standard), debug und eng .

Wenn ein Modul nicht angibt , einen Tag (von LOCAL_MODULE_TAGS ), dessen Tag standardmäßig optional . Ein optionales Modul installiert ist nur , wenn sie von der Produktkonfiguration mit erforderlich ist PRODUCT_PACKAGES .

Dies sind die aktuell definierten Build-Varianten.

Variante Beschreibung
eng Dies ist die Standardgeschmacksrichtung.
  • Installiert Module getaggt mit eng oder debug .
  • Installiert Module gemäß den Produktdefinitionsdateien zusätzlich zu gekennzeichneten Modulen.
  • ro.secure=0
  • ro.debuggable=1
  • ro.kernel.android.checkjni=1
  • adb ist standardmäßig aktiviert.
user Die Variante soll die letzten Release-Bits sein.
  • Installiert Module getaggt mit user .
  • Installiert Module gemäß den Produktdefinitionsdateien zusätzlich zu gekennzeichneten Modulen.
  • ro.secure=1
  • ro.debuggable=0
  • adb ist standardmäßig deaktiviert.
userdebug Der gleiche wie user , mit folgenden Ausnahmen:
  • Auch installiert getaggt mit Modulen debug .
  • ro.debuggable=1
  • adb ist standardmäßig aktiviert.

Richtlinien für das Benutzerdebuggen

Das Ausführen von Userdebug-Builds in Tests hilft Geräteentwicklern, die Leistung und Leistungsfähigkeit von Releases in der Entwicklung zu verstehen. Um die Konsistenz zwischen Benutzer- und Benutzerdebug-Builds aufrechtzuerhalten und zuverlässige Metriken in Builds zu erreichen, die zum Debuggen verwendet werden, sollten Geräteentwickler die folgenden Richtlinien befolgen:

  • userdebug ist definiert als ein Benutzer-Build mit aktiviertem Root-Zugriff, außer:
    • Nur-Benutzerdebug-Apps, die nur bei Bedarf vom Benutzer ausgeführt werden
    • Operationen , die nur während des Leer Wartung (auf Ladegerät / voll geladen), wie die Verwendung laufen dex2oatd gegen dex2oat für Hintergrund compiliert
  • Schließen Sie keine Funktionen ein, die standardmäßig basierend auf dem Build-Typ aktiviert/deaktiviert sind. Entwicklern wird davon abgeraten, jede Form der Protokollierung zu verwenden, die sich auf die Akkulaufzeit auswirkt, wie z. B. Debug-Protokollierung oder Heap-Dumping.
  • Alle Debugging-Features, die standardmäßig in userdebug aktiviert sind, sollten klar definiert und mit allen Entwicklern geteilt werden, die an dem Projekt arbeiten. Sie sollten die Debugging-Funktionen nur für eine begrenzte Zeit aktivieren, bis das Problem, das Sie debuggen möchten, behoben ist.

Anpassen des Builds mit Ressourcen-Overlays

Das Android-Build-System verwendet Ressourcen-Overlays, um ein Produkt zur Build-Zeit anzupassen. Ressourcenüberlagerungen geben Ressourcendateien an, die zusätzlich zu den Standardwerten angewendet werden. Um Ressource - Overlays zu verwenden, ändern Sie das Projekt Buildfile zu Satz PRODUCT_PACKAGE_OVERLAYS auf einen Pfad in Bezug auf Ihr Top-Level - Verzeichnis. Dieser Pfad wird zu einem Schattenstamm, der zusammen mit dem aktuellen Stamm durchsucht wird, wenn das Build-System nach Ressourcen sucht.

Die am häufigsten angepassten Einstellungen werden in der Datei enthaltenen Frameworks / base / Kern / res / res / Werte / config.xml .

Um ein Ressourcen-Overlay für diese Datei einzurichten, fügen Sie das Overlay-Verzeichnis mit einer der folgenden Methoden zur Projekt-Builddatei hinzu:

PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay

oder

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Fügen Sie dann dem Verzeichnis eine Overlay-Datei hinzu, zum Beispiel:

vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml

Irgendwelche Strings oder String - Arrays in der Overlay gefunden config.xml - Datei die in der Originaldatei gefunden ersetzen.

Ein Produkt bauen

Sie können die Quelldateien für Ihr Gerät auf viele verschiedene Arten organisieren. Hier ist eine kurze Beschreibung einer Möglichkeit, eine Pixel-Implementierung zu organisieren.

Pixel ist mit einer Hauptgerätekonfiguration namens implementiert marlin . Aus dieser Gerätekonfiguration wird ein Produkt mit einem Produktdefinitions-Makefile erstellt, das produktspezifische Informationen zum Gerät wie Name und Modell deklariert. Sie können die Ansicht device/google/marlin Verzeichnis , um zu sehen , wie all dies ist eingerichtet.

Schreiben von Produkt-Makefiles

Die folgenden Schritte beschreiben, wie Sie Produkt-Makefiles ähnlich wie bei der Pixel-Produktlinie einrichten:

  1. Erstellen Sie ein device/ <company-name> / <device-name> Verzeichnis für Ihr Produkt. Zum Beispiel device/google/marlin . Dieses Verzeichnis enthält den Quellcode für Ihr Gerät zusammen mit den Makefiles, um sie zu erstellen.
  2. Erstellen Sie eine device.mk Make - Datei, die die Dateien und Module für das Gerät benötigt erklärt. Ein Beispiel finden Sie device/google/marlin/device-marlin.mk .
  3. Erstellen Sie ein Produktdefinitions-Makefile, um ein bestimmtes Produkt basierend auf dem Gerät zu erstellen. Im folgenden wird von Make - Datei genommen device/google/marlin/aosp_marlin.mk als Beispiel. Beachten Sie, dass das Produkt erbt von dem device/google/marlin/device-marlin.mk und vendor/google/marlin/device-vendor-marlin.mk Dateien über das Make - Datei , während auch die produktspezifische Informationen zu erklären, wie Name, Marke, und Modell.
    # Inherit from the common Open Source product configuration
    $(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
    $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk)
    
    PRODUCT_NAME := aosp_marlin
    PRODUCT_DEVICE := marlin
    PRODUCT_BRAND := Android
    PRODUCT_MODEL := AOSP on msm8996
    PRODUCT_MANUFACTURER := Google
    PRODUCT_RESTRICT_VENDOR_FILES := true
    
    PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin
    
    $(call inherit-product, device/google/marlin/device-marlin.mk)
    $(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk)
    
    PRODUCT_PACKAGES += \
        Launcher3QuickStep \
        WallpaperPicker
    

    Siehe Produktdefinition Variablen Einstellung für weitere produktspezifische Variablen , die Sie zu Ihrem Makefiles hinzufügen können.

  4. Erstellen Sie eine AndroidProducts.mk Datei , dass Punkte auf die Makefiles zu diesem Produkt. In diesem Beispiel wird nur das Produktdefinitions-Makefile benötigt. Das folgende Beispiel ist aus device/google/marlin/AndroidProducts.mk (die sowohl Marlin enthält, die Pixel und Fächerfisch das Pixel XL, die die meisten Konfiguration gemeinsam):
    PRODUCT_MAKEFILES := \
    	$(LOCAL_DIR)/aosp_marlin.mk \
    	$(LOCAL_DIR)/aosp_sailfish.mk
    
    COMMON_LUNCH_CHOICES := \
    	aosp_marlin-userdebug \
    	aosp_sailfish-userdebug
    
  5. Erstellen Sie eine BoardConfig.mk Make - Datei , die boardspezifischen Konfigurationen enthält. Ein Beispiel finden Sie device/google/marlin/BoardConfig.mk .
  6. Für Android 9 und nur senken, erstellen Sie eine vendorsetup.sh Datei Ihr Produkt (eine „Mittagessen Combo“) , um den Build zusammen mit einer hinzuzufügen Build - Variante durch einen Bindestrich getrennt. Zum Beispiel:
    add_lunch_combo <product-name>-userdebug
    
  7. An dieser Stelle können Sie weitere Produktvarianten basierend auf demselben Gerät erstellen.

Produktdefinitionsvariablen festlegen

Produktspezifische Variablen werden im Makefile des Produkts definiert. Die Tabelle zeigt einige der Variablen, die in einer Produktdefinitionsdatei verwaltet werden.

Variable Beschreibung Beispiel
PRODUCT_AAPT_CONFIG aapt Konfigurationen zu verwenden , wenn Pakete zu schaffen.
PRODUCT_BRAND Die Marke (z. B. Mobilfunkanbieter), für die die Software gegebenenfalls angepasst wird.
PRODUCT_CHARACTERISTICS aapt Eigenschaften zu ermöglichen , variantenspezifische Ressourcen zu einem Paket hinzufügen. tablet , nosdcard
PRODUCT_COPY_FILES Liste der Wörter wie source_path:destination_path . Die Datei im Quellpfad sollte beim Erstellen dieses Produkts in den Zielpfad kopiert werden. Die Regeln für die Kopierschritte werden in definierten config/makefile - config/makefile .
PRODUCT_DEVICE Name des Industriedesigns. Dies ist auch der Kartenname und das Build - System verwendet es zu lokalisieren BoardConfig.mk . tuna
PRODUCT_LOCALES Eine durch Leerzeichen getrennte Liste von zweibuchstabigen Sprachcode- und zweibuchstabigen Ländercodepaaren, die verschiedene Einstellungen für den Benutzer beschreiben, z. B. die Sprache der Benutzeroberfläche und Uhrzeit, Datum und Währungsformatierung. Die erste locale aufgeführt in PRODUCT_LOCALES wird als das Produkt des Standardgebietsschema verwendet. en_GB , de_DE , es_ES , fr_CA
PRODUCT_MANUFACTURER Name des Herstellers. acme
PRODUCT_MODEL Für den Endbenutzer sichtbarer Name für das Endprodukt.
PRODUCT_NAME Für den Endbenutzer sichtbarer Name für das Gesamtprodukt. Enthalten in den Einstellungen> Bildschirm.
PRODUCT_OTA_PUBLIC_KEYS Liste der öffentlichen Over-the-Air-Schlüssel (OTA) für das Produkt.
PRODUCT_PACKAGES Liste der zu installierenden APKs und Module. Kalenderkontakte
PRODUCT_PACKAGE_OVERLAYS Gibt an, ob Standardressourcen verwendet oder produktspezifische Overlays hinzugefügt werden sollen. vendor/acme/overlay
PRODUCT_SYSTEM_PROPERTIES Liste der Systemeigenschaftszuweisungen im Format "key=value" für die Systempartition. Systemeigenschaften für andere Partitionen können über eingestellt werden PRODUCT_<PARTITION>_PROPERTIES wie in PRODUCT_VENDOR_PROPERTIES für den Verkäufer Partition. Unterstützte Partitionsnamen: SYSTEM , VENDOR , ODM , SYSTEM_EXT und PRODUCT .

Konfigurieren der Standardsystemsprache und des Ländereinstellungsfilters

Verwenden Sie diese Informationen, um den standardmäßigen Sprach- und Systemgebietsschemafilter zu konfigurieren, und aktivieren Sie dann den Gebietsschemafilter für einen neuen Gerätetyp.

Eigenschaften

Konfigurieren Sie sowohl die Standardsprache als auch den Systemgebietsschemafilter mithilfe dedizierter Systemeigenschaften:

  • ro.product.locale : für das Standardgebietsschema einstellen. Diese wird zunächst in der ersten locale in dem eingestellten PRODUCT_LOCALES variabel; Sie können diesen Wert überschreiben. (Weitere Informationen finden Sie in der Einstellung der Produktdefinition Variablen - Tabelle.)
  • ro.localization.locale_filter : zum Einstellen eines locale Filter, ein regulärer Ausdruck angewandt Namen locale. Zum Beispiel:
    • Inklusive Filter: ^(de-AT|de-DE|en|uk).* - erlaubt nur Deutsch (Österreich und Deutschland - Varianten), die alle Englisch - Varianten von Englisch und Ukrainisch
    • Exklusiv - Filter: ^(?!de-IT|es).* - schließt Deutsch (Italien Variante), und alle Varianten der spanischen Sprache.

Aktivieren des Gebietsschemafilters

Um die Filter zu aktivieren, stellen Sie den ro.localization.locale_filter Systemeigenschaft String - Wert.

Durch die Filtereigenschaft Wert einstellen und die Standardsprache durch oem/oem.prop während der Werkskalibrierung Sie Einschränkungen ohne Backen des Filters in das Systemabbild konfigurieren können. Sie stellen sicher , dass diese Eigenschaften werden von der OEM - Partition aufgenommen , indem sie auf die Zugabe von PRODUCT_OEM_PROPERTIES Variable , wie unten angegeben:

# Delegation for OEM customization
PRODUCT_OEM_PROPERTIES += \
    ro.product.locale \
    ro.localization.locale_filter

Dann in der Produktion wird der Ist - Wert geschrieben oem/oem.prop , um die Zielanforderungen anzupassen. Bei diesem Ansatz bleiben die Standardwerte beim Zurücksetzen auf die Werkseinstellungen erhalten, sodass die Anfangseinstellungen für den Benutzer genau wie eine Ersteinrichtung aussehen.

Einstellen von ADB_VENDOR_KEYS für die Verbindung über USB

Die ADB_VENDOR_KEYS Umgebungsvariable ermöglicht Geräteherstellern , den Zugang debug baut (-userdebug und -de, aber nicht -user) über adb ohne manuelle Genehmigung. Normalerweise generiert adb für jeden Client-Computer einen eindeutigen RSA-Authentifizierungsschlüssel, den es an jedes angeschlossene Gerät sendet. Dies ist der RSA-Schlüssel, der im ADB-Autorisierungsdialog angezeigt wird. Alternativ können Sie bekannte Schlüssel in das Systemabbild einbauen und diese mit dem adb-Client teilen. Dies ist für die Betriebssystementwicklung und insbesondere für das Testen nützlich, da die manuelle Interaktion mit dem ADB-Autorisierungsdialog vermieden wird.

Um Lieferantenschlüssel zu erstellen, sollte eine Person (normalerweise ein Release-Manager) Folgendes tun:

  1. Generieren Sie ein Schlüsselpaar mit adb keygen . Bei Google-Geräten generiert Google für jede neue Betriebssystemversion ein neues Schlüsselpaar.
  2. Checken Sie die Schlüsselpaare irgendwo im Quellbaum ein. Google speichert sie in vendor/google/security/adb/ , zum Beispiel.
  3. Stellen Sie die Build - Variable PRODUCT_ADB_KEYS Punkt zu Ihrem Schlüsselverzeichnis. Google tut dies eine durch Hinzufügen Android.mk im Schlüsselverzeichnis - Datei, sagt PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub Dadurch wird sichergestellt, dass wir ein neues Schlüsselpaar für jede OS - Version zu erzeugen erinnern.

Hier ist das Makefile, das Google in dem Verzeichnis verwendet, in dem wir unsere eingecheckten Schlüsselpaare für jede Version speichern:

PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub

ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),)
  $(warning ========================)
  $(warning The adb key for this release)
  $(warning )
  $(warning   $(PRODUCT_ADB_KEYS))
  $(warning )
  $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk)
  $(warning has changed and a new adb key needs to be generated.)
  $(warning )
  $(warning Please run the following commands to create a new key:)
  $(warning )
  $(warning   make -j8 adb)
  $(warning   LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS)))
  $(warning )
  $(warning and upload/review/submit the changes)
  $(warning ========================)
  $(error done)
endif

Um diese Anbieter Schlüssel zu verwenden, muss ein Ingenieur nur das festlegen ADB_VENDOR_KEYS in das Verzeichnis , Umgebungsvariable zu Punkt , in dem die Schlüsselpaar gespeichert sind. Dies sagt adb diese kanonischen Schlüssel zuerst zu versuchen, bevor er sich wieder auf den erzeugten Host - Schlüssel fallen , die manuelle Autorisierung erfordert. Wenn adb nicht auf ein nicht autorisiertes Gerät anschließen, wird die Fehlermeldung vor , dass Sie setzen ADB_VENDOR_KEYS wenn es nicht bereits gesetzt ist.