Diese Seite wurde von der Cloud Translation API übersetzt.

Neues Gerät hinzufügen

Erstellen Sie mithilfe der Informationen auf dieser Seite die Makefiles für Ihr Gerät und Produkt.

Für jedes neue Android-Modul muss eine Konfigurationsdatei vorhanden sein, die das Build-System anweist mit Modulmetadaten, Abhängigkeiten zur Kompilierungszeit und Anweisungen zur Paketerstellung. Android verwendet die Soong-Build-System Weitere Informationen über die Android-Version finden Sie unter Entwickeln von Android . zu erstellen.

Informationen zu Build-Ebenen

Die Build-Hierarchie umfasst die Abstraktionsebenen, die dem die physische Beschaffenheit eines Geräts. Diese Ebenen werden in der folgenden Tabelle beschrieben. Jede Ebene bezieht sich in einer 1:n-Beziehung auf die Ebene darüber. Für Architektur kann z. B. mehr als ein Board und jede Tafel mehr als ein Produkt. Sie können ein Element in einem bestimmten Layer als die Spezialisierung eines Elements im selben Layer, wodurch das Kopieren und vereinfacht die Wartung.

Ebene	Beispiel	Beschreibung
Produkt	myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk	Die Produktebene definiert die Funktionsspezifikation eines Versands z. B. die Module, die unterstützten Sprachen und für verschiedene Sprachen konfigurieren. Mit anderen Worten, dies ist der Name des gesamten Produkts. Produktspezifische Variablen werden in Makefiles der Produktdefinition. Produkte können von anderen Elementen übernommen werden, Produktdefinitionen, was die Wartung vereinfacht. Eine gängige Methode ist das Erstellen eines Basisprodukts mit Funktionen, alle Produkte und erstellen Sie dann Produktvarianten basierend auf dieser Basis. Produkt. Beispiel: Zwei Produkte, die sich nur durch ihre Funkschnittstellen (CDMA oder GSM) vom selben Basisprodukt definiert kein Radio.
Board/Gerät	Marlin, blaue Linie, Koralle	Die Platten-/Geräteschicht ist die Bitübertragungsschicht aus Kunststoff auf der Gerät (d. h. das Industriedesign des Geräts). Diese Ebene stellt auch Schaltpläne eines Produkts. Dazu gehören die Peripheriegeräte auf dem Board und ihre Konfiguration. Die verwendeten Namen sind lediglich Codes für verschiedene Boards/Geräte. Konfigurationen.
Bogen	Verzweigung, x86, Verzweigung64, x86_64	Die Architekturschicht beschreibt die Prozessorkonfiguration und auf dem Board ausgeführt wird.

Build-Varianten verwenden

Bei der Entwicklung für ein bestimmtes Produkt ist es hilfreich, Versionen des endgültigen Release-Builds. In einem Modul kann das Modul Tags mit LOCAL_MODULE_TAGS angeben, Dabei kann es sich um einen oder mehrere Werte von optional (Standard) handeln, debug und eng.

Wenn für ein Modul kein Tag angegeben ist (durch LOCAL_MODULE_TAGS), ist es Tag standardmäßig auf optional gesetzt. Ein optionales Modul wird nur installiert, Dies ist für die Produktkonfiguration mit PRODUCT_PACKAGES erforderlich.

Dies sind die derzeit definierten Build-Varianten.

Variante	Beschreibung
`eng`	Dies ist der Standard-Geschmacksrichtung. Installiert Module mit dem Tag `eng` oder `debug`. Installiert Module gemäß den Produktdefinitionsdateien in zu getaggten Modulen. `ro.secure=0` `ro.debuggable=1` `ro.kernel.android.checkjni=1` `adb` ist standardmäßig aktiviert.
`user`	Die Variante, die die endgültigen Release-Bits sein soll. Installiert mit `user` getaggte Module. Installiert Module gemäß den Produktdefinitionsdateien in zu getaggten Modulen. `ro.secure=1` `ro.debuggable=0` `adb` ist standardmäßig deaktiviert.
`userdebug`	Entspricht `user`, mit folgenden Ausnahmen: <ph type="x-smartling-placeholder"> </ph> Außerdem werden mit `debug` getaggte Module installiert. `ro.debuggable=1` `adb` ist standardmäßig aktiviert.

Richtlinien zum Debuggen von Nutzern

Das Ausführen von Fehlerbehebungs-Builds in Tests hilft Geräteherstellern, die Leistung und Macht von Releases in der Entwicklung zu verbessern. Um Einheitlichkeit zu wahren zwischen Benutzer- und Nutzer-Debug-Builds und um zuverlässige Messwerte in Builds zu erzielen. zur Fehlerbehebung sollten Gerätehersteller die folgenden Richtlinien beachten:

„userdebug“ ist definiert als ein Nutzer-Build mit aktiviertem Root-Zugriff, mit folgenden Ausnahmen: <ph type="x-smartling-placeholder">
- Apps zur Fehlerbehebung, die nur bei Bedarf vom Nutzer ausgeführt werden
- Vorgänge, die nur während der Wartung im Ruhezustand (auf dem Ladegerät/vollständig) ausgeführt werden kostenpflichtig), z. B. dex2oatd im Vergleich zu dex2oat für Hintergrundkompilierungen
Schließen Sie keine Features ein, die standardmäßig basierend auf dem Build-Typ aktiviert oder deaktiviert sind. Entwicklern wird davon abgeraten, jegliche Art der Protokollierung zu verwenden, die die Akkulaufzeit beeinträchtigt. Fehlerprotokollierung oder Heap-Dumping durchführen.
Alle Debugging-Funktionen, die standardmäßig in „UserDebug“ aktiviert sind, sollten klar definiert sein. und an alle Entwickelnden weitergegeben, die an dem Projekt arbeiten. Sie sollten Debugging-Funktionen aktivieren wenn das Problem behoben ist.

Build mit Ressourcen-Overlays anpassen

Das Android-Build-System nutzt Ressourcen-Overlays zur Anpassung bei der Erstellung eines Produkts. Ressourcen-Overlays geben Ressource an -Dateien, die zusätzlich zu den Standardeinstellungen angewendet werden. Ändern Sie das Projekt, um Ressourcen-Overlays zu verwenden Buildfile, um PRODUCT_PACKAGE_OVERLAYS auf einen Pfad relativ zu Ihrem Verzeichnis der obersten Ebene. Dieser Pfad wird zu einer Schattenwurzel, die zusammen mit das aktuelle Stammverzeichnis verwendet, wenn das Build-System nach Ressourcen sucht.

Die am häufigsten angepassten Einstellungen sind in der Datei frameworks/base/core/res/res/values/config.xml enthalten.

Um ein Ressourcen-Overlay für diese Datei einzurichten, fügen Sie das Overlay-Verzeichnis zum Projekt-Build-Datei mit einem der folgenden Elemente erstellen:

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

oder

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

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

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

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

Produkt entwickeln

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

Pixel ist mit einer Hauptgerätekonfiguration namens marlin Anhand dieser Gerätekonfiguration wird ein Produkt mit einer Makefile zur Produktdefinition, in dem produktspezifische Informationen wie Name und Modell angezeigt. Sie können die device/google/marlin, um zu sehen, wie dies eingerichtet ist.

Produkt-Makefiles schreiben

In den folgenden Schritten wird beschrieben, wie Sie Produkt-Makefiles auf ähnliche Weise einrichten. Pixel-Produktlinie

device/<company-name>/<device-name> erstellen für Ihr Produkt. Beispiel: device/google/marlin. Dieses Verzeichnis wird Quellcode enthalten für Ihr Gerät zusammen mit den Makefiles für die Erstellung.
Erstellen Sie ein device.mk-Makefile, in dem die Dateien und Module deklariert sind, die für das . Ein Beispiel findest du unter device/google/marlin/device-marlin.mk.

Erstellen Sie ein Produktdefinitions-Makefile, um ein bestimmtes Produkt auf Grundlage des Geräts zu erstellen. Die Das folgende Makefile stammt aus device/google/marlin/aosp_marlin.mk als Beispiel. Beachten Sie, dass das Produkt device/google/marlin/device-marlin.mk und vendor/google/marlin/device-vendor-marlin.mk-Dateien über das Makefile, während Außerdem werden produktspezifische Informationen wie Name, Marke und Modell angegeben.

# 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

Weitere Informationen finden Sie unter Variablen für Produktdefinitionen festlegen. produktspezifische Variablen, die Sie Ihren Makefiles hinzufügen können.

Erstellen Sie eine AndroidProducts.mk-Datei, die auf die Makefiles des Produkts verweist. In In diesem Beispiel wird nur das Makefile zur Produktdefinition benötigt. Das Beispiel unten stammt aus device/google/marlin/AndroidProducts.mk (enthält sowohl Marlin, Pixel, und Sailfish, dem Pixel XL, das die meisten Konfigurationen verwendet:
```
PRODUCT_MAKEFILES := \
	$(LOCAL_DIR)/aosp_marlin.mk \
	$(LOCAL_DIR)/aosp_sailfish.mk

COMMON_LUNCH_CHOICES := \
	aosp_marlin-userdebug \
	aosp_sailfish-userdebug
```
Erstellen Sie ein BoardConfig.mk-Makefile, das boardspezifische Konfigurationen enthält. Ein Beispiel findest du unter device/google/marlin/BoardConfig.mk.
Nur für Android 9 und niedriger: vendorsetup.sh-Datei, zu der dein Produkt (ein „Mittagsmenü“) hinzugefügt werden soll den Build zusammen mit einer Build-Variante getrennt durch einen Bindestrich. Hier einige Beispiele:
```
add_lunch_combo <product-name>-userdebug
```
Jetzt können Sie weitere Produktvarianten für dasselbe Gerät erstellen.

Variablen für Produktdefinitionen festlegen

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

Variable	Beschreibung	Beispiel
`PRODUCT_AAPT_CONFIG`	`aapt`-Konfigurationen, die beim Erstellen von Paketen verwendet werden sollen.
`PRODUCT_BRAND`	Die Marke (z. B. der Mobilfunkanbieter), für die die Software angepasst ist.
`PRODUCT_CHARACTERISTICS`	`aapt`-Eigenschaften, um variantenspezifische Ressourcen zu einem Paket hinzuzufügen.	`tablet`, `nosdcard`
`PRODUCT_COPY_FILES`	Liste mit Wörtern wie `source_path:destination_path`. Die Datei im Quellpfad sollte beim Erstellen dieses Produkts in den Zielpfad kopiert werden. Regeln für die Kopie Schritte sind in `config/makefile` definiert.
`PRODUCT_DEVICE`	Name des Industriedesigns. Dies ist auch der Name des Boards, der vom Build-System verwendet wird. um `BoardConfig.mk` zu finden.	`tuna`
`PRODUCT_LOCALES`	Eine durch Leerzeichen getrennte Liste mit zweistelligen Sprachcodes und zweistelligen Ländercodepaaren, die beschreiben verschiedene Einstellungen für den Nutzer, z. B. UI-Sprache, Uhrzeit, Datum und Währungsformatierung. Die erste in `PRODUCT_LOCALES` aufgeführte Sprache wird verwendet als die Standardsprache des Produkts.	`en_GB`, `de_DE`, `es_ES`, `fr_CA`
`PRODUCT_MANUFACTURER`	Name des Herstellers.	`acme`
`PRODUCT_MODEL`	Für Endnutzer sichtbarer Name für das Endprodukt.
`PRODUCT_NAME`	Für Endnutzer sichtbarer Name für das Gesamtprodukt. Erscheint in den Einstellungen > Info angezeigt.
`PRODUCT_OTA_PUBLIC_KEYS`	Liste der öffentlichen OTA-Schlüssel (Over The Air) 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 Zuweisungen von Systemattributen im Format `"key=value"` für die Systempartitionierung. Systemeigenschaften für andere Partitionen können über `PRODUCT_<PARTITION>_PROPERTIES` wie in `PRODUCT_VENDOR_PROPERTIES` für die Anbieterpartition. Unterstützte Partition Namen: `SYSTEM`, `VENDOR`, `ODM`, `SYSTEM_EXT` und `PRODUCT`.

Standardfilter für Systemsprache und Gebietsschema konfigurieren

Konfigurieren Sie anhand dieser Informationen den Filter für die Standardsprache und das Gebietsschema für das System und aktivieren Sie dann den Sprachfilter für einen neuen Gerätetyp.

Properties

Sie können sowohl die Standardsprache als auch den Sprachfilter des Systems über ein spezielles System konfigurieren. Eigenschaften:

ro.product.locale: zum Festlegen der Standardsprache. Dies wird anfangs auf die erste Sprache in der Variablen PRODUCT_LOCALES können Sie für diesen Wert. (Weitere Informationen finden Sie in der Variablen für Produktdefinitionen festlegen)
ro.localization.locale_filter: zum Festlegen eines Sprachfilters mithilfe von einen regulären Ausdruck, der auf Gebietsschemanamen angewendet wird. Hier einige Beispiele: <ph type="x-smartling-placeholder">
- Einschlussfilter: ^(de-AT|de-DE|en|uk).* – nur Deutsch (Deutschland und Österreich) zulässig -Varianten), alle englischen und ukrainischen Varianten
- Exklusiver Filter: ^(?!de-IT|es).* – schließt Deutsch (Italienische Variante) und alle aus Varianten des Spanischen.

Sprachfilter aktivieren

Legen Sie den Stringwert für die Systemeigenschaft ro.localization.locale_filter fest, um den Filter zu aktivieren.

Durch Festlegen des Werts der Filtereigenschaft und der Standardsprache über oem/oem.prop während können Sie Einschränkungen konfigurieren, ohne den Filter in das System-Image einbinden zu müssen. Sie stellen sicher, dass diese Eigenschaften von der OEM-Partition übernommen werden, indem Sie sie zum PRODUCT_OEM_PROPERTIES wie unten angegeben:

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

Dann werden in der Produktion die tatsächlichen Werte in oem/oem.prop geschrieben, um den Zielwert Anforderungen. Bei diesem Ansatz bleiben die Standardwerte beim Zurücksetzen auf die Werkseinstellungen erhalten, sodass der Anfangseinstellungen genau wie die Ersteinrichtung aussehen.

ADB_VENDOR_KEYS für Verbindung über USB festlegen

Die Umgebungsvariable ADB_VENDOR_KEYS ermöglicht Geräteherstellern den Zugriff auf Debug-fähige Builds (-userdebug und -eng, aber nicht -user) über ADB ohne manuelle Autorisierung. Normalerweise generiert adb einen eindeutigen RSA-Authentifizierungsschlüssel für jeden Client-Computer, den es dann mit jedem verbundenen Gerät. Dies ist der RSA-Schlüssel, der im ADB-Autorisierungsdialog angezeigt wird. Als Alternativ können Sie bekannte Schlüssel in das System-Image einbauen und mit dem Adb-Client teilen. Dies ist nützlich für die Betriebssystementwicklung und insbesondere für Tests, da Sie so die Notwendigkeit vermeiden können, mit dem ADB-Autorisierungsdialog interagieren.

Zum Erstellen von Anbieterschlüsseln sollte eine Person (in der Regel ein Release-Manager) die folgenden Schritte ausführen:

Generieren Sie ein Schlüsselpaar mit adb keygen. Für Google-Geräte generiert Google Schlüsselpaar für jede neue Betriebssystemversion ein.
Prüfen Sie die Schlüsselpaare irgendwo in der Quellstruktur. werden von Google gespeichert in vendor/google/security/adb/.
Legen Sie die Build-Variable PRODUCT_ADB_KEYS so fest, dass sie auf Ihr Schlüsselverzeichnis verweist. Dazu fügt Google dem Schlüsselverzeichnis die Datei Android.mk hinzu, in der steht: PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub, die sorgt dafür, dass für jede Betriebssystemversion ein neues Schlüsselpaar generiert werden muss.

Hier ist das Makefile, das Google in dem Verzeichnis verwendet, in dem unsere eingecheckten Schlüsselpaare Release:

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

Zur Verwendung dieser Anbieterschlüssel muss ein Entwickler nur die ADB_VENDOR_KEYS festlegen um auf das Verzeichnis zu verweisen, in dem die Schlüsselpaare gespeichert sind. Dadurch wird adb angewiesen, diese kanonischen Schlüssel zuerst auszuprobieren, bevor auf den generierten Hostschlüssel, der eine manuelle Autorisierung erfordert. Wenn adb keine Verbindung zu einem nicht autorisierten Nutzer herstellen kann Gerät verwenden, schlägt die Fehlermeldung vor, ADB_VENDOR_KEYS festzulegen. festgelegt ist.