Dodaj nowe urządzenie

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. Instaluje moduły oznaczone tagiem eng lub debug. Instaluje moduły zgodnie z plikami definicji produktu w w uzupełnieniu do otagowanych modułów. ro.secure=0 ro.debuggable=1 ro.kernel.android.checkjni=1 Usługa adb jest domyślnie włączona.
user	Wariant, który miał być ostatecznymi elementami wydania. Instaluje moduły oznaczone tagiem user. Instaluje moduły zgodnie z plikami definicji produktu w w uzupełnieniu do otagowanych modułów. ro.secure=1 ro.debuggable=0 Funkcja adb jest domyślnie wyłączona.
userdebug	Taka sama jak user, z tymi wyjątkami: Instaluje także moduły oznaczone tagiem debug. ro.debuggable=1 Usługa adb jest domyślnie włączona.

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 z dex2oat 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:

1. 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ć.
2. Utwórz plik Makefile device.mk deklarujący pliki i moduły wymagane przez urządzenia. Przykład: device/google/marlin/device-marlin.mk.
3. 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 parametru device/google/marlin/device-marlin.mk i vendor/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.

4. 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 z device/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
   

5. Utwórz plik Makefile BoardConfig.mk, który zawiera konfiguracje płyt. Przykład: device/google/marlin/BoardConfig.mk.
6. 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
   

7. 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 zmiennej PRODUCT_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.

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:

1. Wygeneruj parę kluczy za pomocą adb keygen. W przypadku urządzeń Google generujemy nowy dla każdej nowej wersji systemu operacyjnego.
2. Sprawdź pary kluczy w drzewie źródłowym. Google przechowuje je w vendor/google/security/adb/.
3. Ustaw zmienną kompilacji PRODUCT_ADB_KEYS tak, aby wskazywała katalog kluczy. W tym celu Google dodaje do katalogu kluczy plik Android.mk o nazwie PRODUCT_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.