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.
|
user
|
Die Variante, die die endgültigen Release-Bits sein soll.
|
userdebug
|
Entspricht user , mit folgenden Ausnahmen:
<ph type="x-smartling-placeholder">
|
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">
- </ph>
- 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 zudex2oat
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 unterdevice/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 Produktdevice/google/marlin/device-marlin.mk
undvendor/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 ausdevice/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 unterdevice/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 VariablenPRODUCT_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">- </ph>
- 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.
- Einschlussfilter:
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 DateiAndroid.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.