Użyj informacji z tej strony, aby utworzyć pliki programu Makefiles na swoim urządzeniu usługi.
Każdy nowy moduł Androida musi mieć plik konfiguracji, który będzie kierował systemem kompilacji z metadanymi modułów, zależnościami czasu kompilacji i instrukcjami pakowania. Android używa System kompilacji Soong. Więcej informacji o Androidzie znajdziesz w artykule Tworzenie Androida. systemu kompilacji.
Informacje o warstwach kompilacji
Hierarchia kompilacji obejmuje warstwy abstrakcji, które odpowiadają budowy urządzenia. Opis tych warstw znajdziesz w tabeli poniżej. Każda warstwa jest powiązana z jej warstwą w relacji jeden do wielu. Dla: architektura może mieć więcej niż jedną tablicę, a każda z nich może mieć więcej niż jednego produktu. Element w danej warstwie możesz zdefiniować jako specjalizację elementu w tej samej warstwie, co eliminuje konieczność kopiowania upraszcza konserwację.
Warstwa | Przykład | Opis |
---|---|---|
Produkt | myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk | Warstwa produktu definiuje specyfikację cech dostawy takich jak moduły do tworzenia, obsługiwane języki w różnych językach. Inaczej mówiąc, jest to nazwa całego produktu. Zmienne związane z produktem definiuje się tutaj: Plików do tworzenia definicji usługi. Usługa może dziedziczyć z innych usług definicje produktów w celu uproszczenia obsługi. Popularną metodą jest stworzenie usługi podstawowej zawierającej funkcje, które dotyczą wszystkich produktów, a potem na podstawie tych danych usługi. Na przykład 2 produkty różniące się tylko ich radia (CDMA i GSM) mogą dziedziczyć dane z tego samego produktu podstawowego, nie ma definicji radia. |
Płyta/urządzenie | marlin, niebieska linia, koral | Warstwa płyty/urządzenia to fizyczna warstwa plastiku urządzenia (czyli konstrukcji przemysłowej urządzenia). Ta warstwa reprezentuje również gołą warstwę Schemat produktu. Są to urządzenia peryferyjne na płycie i ich konfiguracji. Używane nazwy to jedynie kody różnych plansz/urządzeń. konfiguracji. |
Łukowe | ramię, x86, arm64, x86_64 | Warstwa architektury opisuje konfigurację procesora Interfejs binarny aplikacji (ABI) uruchomiony na płytce. |
Używanie wariantów kompilacji
Przy tworzeniu konkretnego produktu warto mieć
wersji finalnej. W module
definicji, moduł może zawierać tagi z parametrami LOCAL_MODULE_TAGS
,
która może być co najmniej jedną wartością optional
(domyślnie),
debug
i eng
.
Jeśli moduł nie określa tagu (przez LOCAL_MODULE_TAGS
), jego
domyślna wartość tagu to optional
. Moduł opcjonalny jest instalowany tylko wtedy,
jest wymagany przez konfigurację usługi w: PRODUCT_PACKAGES
.
To są obecnie zdefiniowane warianty kompilacji.
Wariant | Opis |
---|---|
eng
|
To jest rodzaj domyślny.
|
user
|
Wariant, który miał być ostatecznymi elementami wydania.
|
userdebug
|
Taka sama jak user , z tymi wyjątkami:
|
Wskazówki dotyczące debugowania użytkowników
Uruchamianie kompilacji debugowania użytkownika w ramach testów pomaga deweloperom urządzeń zrozumieć, na wydajności i możliwościach wersji rozwojowych. Aby zachować spójność między kompilacjami użytkowników a kompilacjami debugowanymi przez użytkowników, oraz uzyskać wiarygodne dane w kompilacji. do debugowania, deweloperzy urządzeń powinni przestrzegać tych wskazówek:
- userdebug jest definiowany jako kompilacja użytkownika z włączonym dostępem na poziomie roota, z wyjątkiem tych sytuacji:
- aplikacje wyłącznie debugujące użytkownika, które są uruchamiane tylko na żądanie użytkownika.
- Operacje wykonywane tylko podczas konserwacji bezczynnej (przy ładowarce lub w pełni
naładowane), np. korzystanie z
dex2oatd
w porównaniu zdex2oat
do kompilowania w tle
- Nie dodawaj funkcji, które są domyślnie włączone lub wyłączone na podstawie typu kompilacji. Odradzamy deweloperom korzystanie z jakichkolwiek form rejestrowania, które mogą mieć wpływ na żywotność baterii, takich jak: zapisywanie danych debugowania lub zrzut stosu.
- Wszystkie funkcje debugowania, które są domyślnie włączone w programie userdebug, powinny być jasno określone i udostępniane wszystkim programistom pracującym nad projektem. Należy włączyć funkcje debugowania tylko przez ograniczony czas, aż do rozwiązania problemu, który próbujesz debugować.
Dostosuj kompilację za pomocą nakładek zasobów
System kompilacji Androida wykorzystuje nakładki zasobów, aby dostosować
i produktami w czasie tworzenia. Nakładki zasobów określają zasób
które są stosowane poza domyślnymi. Aby używać nakładek zasobów, zmodyfikuj projekt
plik buildfile, aby ustawić PRODUCT_PACKAGE_OVERLAYS
na
w stosunku do katalogu najwyższego poziomu. Ścieżka staje się rdzeniem cienia wyszukiwanej razem z
obecny poziom główny, gdy system kompilacji wyszukuje zasoby.
Ustawienia najczęściej dostosowywane znajdują się w pliku frameworks/base/core/res/res/values/config.xml.
Aby skonfigurować nakładkę zasobów w tym pliku, dodaj katalog nakładki do pliku plik kompilacji projektu przy użyciu jednego z tych elementów:
PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay
lub
PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay
Następnie dodaj do katalogu plik z obrazem nad powierzchnią, np.:
vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml
Wszystkie ciągi i tablice ciągu znaków znalezione w pliku config.xml
nakładki zostaną zastąpione
tych, które znajdują się w oryginalnym pliku.
Tworzenie produktu
Pliki źródłowe możesz porządkować na wiele różnych sposobów. Oto krótkie podsumowanie i opis jednego ze sposobów organizacji implementacji telefonu Pixel.
Pixel został zaimplementowany z główną konfiguracją urządzenia o nazwie
marlin
Na podstawie tej konfiguracji urządzenia produkt jest tworzony za pomocą
plik z definicją produktu, który deklaruje szczegółowe informacje o produkcie.
urządzenie, takie jak nazwa i model. Możesz wyświetlić
device/google/marlin
, aby zobaczyć, jak wszystko jest skonfigurowane.
Napisz pliki do tworzenia produktów
Poniżej opisujemy, jak skonfigurować pliki marek w podobny sposób. do produktów z linii produktów Pixel:
- Utwórz
device/<company-name>/<device-name>
dla Twojego usługi. Na przykład:device/google/marlin
. Ten katalog będzie zawierał kod źródłowy wraz z plikami Makefiles, aby je utworzyć. - Utwórz plik Makefile
device.mk
deklarujący pliki i moduły wymagane przez urządzenia. Przykład:device/google/marlin/device-marlin.mk
. - Utwórz plik Makefile definicji produktu, aby utworzyć konkretny produkt na podstawie urządzenia.
ten plik Makefile został pobrany z
device/google/marlin/aosp_marlin.mk
jako przykład. Zwróć uwagę, że usługa dziedziczy z parametrudevice/google/marlin/device-marlin.mk
ivendor/google/marlin/device-vendor-marlin.mk
plików w pliku Makefile podając też informacje o konkretnym produkcie, takie jak nazwa, marka i model.# 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
Dodatkowe informacje znajdziesz w artykule Ustawianie zmiennych definicji produktu. zmiennych konkretnych produktów, które możesz dodać do plików Makefile.
- Utwórz plik
AndroidProducts.mk
wskazujący pliki marki produktu. W W tym przykładzie potrzebny jest tylko plik Makefile definicji produktu. Przykład poniżej pochodzi zdevice/google/marlin/AndroidProducts.mk
(która zawiera zarówno marlin, jak i Pixel, i żaglicę czy Pixel XL, który ma większość konfiguracji):PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/aosp_marlin.mk \ $(LOCAL_DIR)/aosp_sailfish.mk COMMON_LUNCH_CHOICES := \ aosp_marlin-userdebug \ aosp_sailfish-userdebug
- Utwórz plik Makefile
BoardConfig.mk
, który zawiera konfiguracje płyt. Przykład:device/google/marlin/BoardConfig.mk
. - Tylko tylko na Androidzie 9 i starszych wersjach utwórz plik
vendorsetup.sh
plik, do którego należy dodać produkt (zestaw na lunch), do kompilację wraz z wariantem kompilacji. są oddzielone myślnikiem. Na przykład:add_lunch_combo <product-name>-userdebug
- W tym momencie możesz utworzyć więcej wersji produktu na podstawie tego samego urządzenia.
Ustawianie zmiennych definicji produktu
Zmienne poszczególnych produktów są zdefiniowane w pliku Makefile produktu. Tabela zawiera niektóre z tych zmiennych przechowywanych w pliku definicji produktu.
Zmienna | Opis | Przykład |
---|---|---|
PRODUCT_AAPT_CONFIG
|
Konfiguracje aapt , które mają być używane podczas tworzenia pakietów.
|
|
PRODUCT_BRAND
|
Marka (np. operator), do której dostosowane oprogramowanie jest dostosowane. | |
PRODUCT_CHARACTERISTICS
|
aapt , które umożliwiają dodanie do pakietu zasobów konkretnych wariantów.
|
tablet , nosdcard
|
PRODUCT_COPY_FILES
|
Lista słów, np. source_path:destination_path . Plik w ścieżce źródłowej
został skopiowany do ścieżki docelowej podczas tworzenia tego produktu. Zasady dotyczące kopiowania
kroki są zdefiniowane w config/makefile .
|
|
PRODUCT_DEVICE
|
Nazwa wzoru przemysłowego. Jest to również nazwa płyty, która jest używana przez system kompilacji
aby zlokalizować urządzenie BoardConfig.mk .
|
tuna
|
PRODUCT_LOCALES
|
Rozdzielona spacjami lista dwuliterowych kodów językowych i dwuliterowych par kodów krajów,
opisują kilka ustawień użytkownika, takich jak język interfejsu, godzina, data,
formatu waluty. Pierwsze ustawienie regionalne wymienione w tabeli PRODUCT_LOCALES jest używane jako
na domyślnym języku usługi.
|
en_GB , de_DE , es_ES , fr_CA
|
PRODUCT_MANUFACTURER
|
Nazwa producenta. |
acme
|
PRODUCT_MODEL
|
Nazwa produktu widoczna dla użytkownika. | |
PRODUCT_NAME
|
Nazwa produktu widoczna dla użytkownika. Widoczne w sekcji Ustawienia > Ekran Informacje. | |
PRODUCT_OTA_PUBLIC_KEYS
|
Lista kluczy publicznych usługi bezprzewodowych (OTA) | |
PRODUCT_PACKAGES
|
Lista plików APK i modułów do zainstalowania. | Kontakty z kalendarza |
PRODUCT_PACKAGE_OVERLAYS
|
Wskazuje, czy należy użyć zasobów domyślnych, czy dodać nakładki dotyczące konkretnych produktów. |
vendor/acme/overlay
|
PRODUCT_SYSTEM_PROPERTIES
|
Lista przypisań właściwości systemowych w formacie "key=value" dla
partycji systemu. Właściwości systemowe innych partycji można ustawić w
PRODUCT_<PARTITION>_PROPERTIES na dzień
PRODUCT_VENDOR_PROPERTIES dla partycji dostawcy. Obsługiwana partycja
nazwy: SYSTEM , VENDOR , ODM ,
SYSTEM_EXT i PRODUCT .
|
Skonfiguruj domyślny filtr języka i regionu systemu
Użyj tych informacji, aby skonfigurować domyślny filtr języka i języka systemu, a następnie włącz filtra ustawień regionalnych dla nowego typu urządzenia.
Właściwości
Skonfiguruj zarówno język domyślny, jak i filtr ustawień regionalnych systemu za pomocą dedykowanego systemu właściwości:
ro.product.locale
: służy do ustawienia domyślnego języka. Początkowo jest to język w zmiennejPRODUCT_LOCALES
; możesz zastąpić tę wartość. (Więcej informacji znajdziesz w tabeli Ustawianie zmiennych definicji produktu).ro.localization.locale_filter
: aby ustawić filtr języka przy użyciu: wyrażenie regularne stosowane do nazw języków. Na przykład:- Filtr integracji społecznej:
^(de-AT|de-DE|en|uk).*
– dopuszcza tylko język niemiecki (Austria i Niemcy) warianty), wszystkie warianty angielskie i ukraińskie - Filtr wyłączny:
^(?!de-IT|es).*
– wyklucza niemiecki (wariant we Włoszech) i wszystkie odmian hiszpańskiego.
- Filtr integracji społecznej:
Włącz filtr ustawień regionalnych
Aby włączyć filtr, ustaw wartość ciągu właściwości systemowej ro.localization.locale_filter
.
Ustawiając wartość właściwości filtra i domyślny język za pomocą opcji oem/oem.prop
podczas
kalibracji fabrycznej, możesz skonfigurować ograniczenia bez umieszczania filtra w obrazie systemu.
Aby mieć pewność, że te właściwości są pobierane z partycji OEM, dodaj je do
PRODUCT_OEM_PROPERTIES
zgodnie z poniższym opisem:
# Delegation for OEM customization PRODUCT_OEM_PROPERTIES += \ ro.product.locale \ ro.localization.locale_filter
Następnie w środowisku produkcyjnym rzeczywiste wartości są zapisywane w oem/oem.prop
, aby odzwierciedlić wartość docelową.
. W ten sposób podczas przywracania ustawień fabrycznych zachowywane są wartości domyślne,
ustawienia początkowe wyglądają dokładnie tak samo jak pierwsze ustawienia.
Ustaw ADB_VENDOR_KEYS, aby połączyć się przez USB
Zmienna środowiskowa ADB_VENDOR_KEYS
umożliwia producentom urządzeń dostęp
kompilacje z możliwością debugowania (-userdebug i -eng, ale nie -user) zamiast narzędzia adb bez ręcznej autoryzacji.
Normalnie adb generuje dla każdego komputera kliencki unikalny klucz uwierzytelniania RSA, który przesyła
na dowolnym połączonym urządzeniu. To jest klucz RSA widoczny w oknie autoryzacji adb. Jako
możesz też osadzić znane klucze w obrazie systemu i udostępnić je klientowi adb.
Jest to przydatne przy tworzeniu systemów operacyjnych, a zwłaszcza przy testowaniu, ponieważ eliminuje konieczność ręcznego
wchodzi w interakcję z oknem autoryzacji adb.
Aby utworzyć klucze dostawcy, jedna osoba (zwykle menedżer ds. wersji) powinna:
- Wygeneruj parę kluczy za pomocą
adb keygen
. W przypadku urządzeń Google generujemy nowy dla każdej nowej wersji systemu operacyjnego. - Sprawdź pary kluczy w drzewie źródłowym. Google przechowuje je w
vendor/google/security/adb/
. - Ustaw zmienną kompilacji
PRODUCT_ADB_KEYS
tak, aby wskazywała katalog kluczy. W tym celu Google dodaje do katalogu kluczy plikAndroid.mk
o nazwiePRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub
, czyli pomaga nam pamiętać o wygenerowaniu nowej pary kluczy dla każdej wersji systemu operacyjnego.
Oto plik Makefile, którego Google używa w katalogu, w którym przechowujemy pary kluczy meldowanych dla każdej wersja:
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
Aby można było używać tych kluczy dostawcy, inżynier musi tylko skonfigurować ADB_VENDOR_KEYS
i wskazuje katalog, w którym są przechowywane pary kluczy.
Dzięki temu adb
najpierw spróbuje użyć tych kluczy kanonicznych, a potem przełączy się na wygenerowane
klucz hosta, który wymaga ręcznej autoryzacji. Gdy adb
nie może połączyć się z nieautoryzowanym urządzeniem
urządzenia, komunikat o błędzie będzie sugerować ustawienie ADB_VENDOR_KEYS
, jeśli nie jest
już ustawione.