Yeni bir cihaz ekleme

Cihazınız ve ürününüz için makefile dosyaları oluşturmak için bu sayfadaki bilgileri kullanın.

Her yeni Android modülünün, yapı sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme yönergeleriyle yönlendirmek için bir yapılandırma dosyası olmalıdır. Android , Soong derleme sistemini kullanır. Android derleme sistemi hakkında daha fazla bilgi için bkz. Android Derleme .

Derleme katmanlarını anlama

Yapı hiyerarşisi, bir cihazın fiziksel yapısına karşılık gelen soyutlama katmanlarını içerir. Bu katmanlar aşağıdaki tabloda açıklanmıştır. Her katman, bir-çok ilişkisinde bir üst katmanla ilişkilidir. Örneğin bir mimaride birden fazla kart olabilir ve her kartta birden fazla ürün olabilir. Belirli bir katmandaki bir öğeyi, aynı katmandaki bir öğenin uzmanlaşması olarak tanımlayabilirsiniz; bu, kopyalamayı ortadan kaldırır ve bakımı basitleştirir.

Yapı varyantlarını kullanma

Belirli bir ürün için oluştururken, son sürüm yapısında küçük varyasyonlara sahip olmak yararlıdır. Bir modül tanımında, modül, optional bağlı (varsayılan), debug ve eng değerlerinin bir veya daha fazlası olabilen LOCAL_MODULE_TAGS ile etiketler belirtebilir.

Bir modül bir etiket belirtmezse ( LOCAL_MODULE_TAGS tarafından), etiketi varsayılan olarak optional olur. İsteğe bağlı bir modül, yalnızca PRODUCT_PACKAGES ile ürün yapılandırması gerektiriyorsa kurulur.

Bunlar, şu anda tanımlanmış yapı değişkenleridir.

Kullanıcı hata ayıklama yönergeleri

Testte userdebug derlemelerini çalıştırmak, cihaz geliştiricilerin geliştirme aşamasındaki sürümlerin performansını ve gücünü anlamalarına yardımcı olur. Kullanıcı ve kullanıcı hata ayıklama yapıları arasında tutarlılığı korumak ve hata ayıklama için kullanılan yapılarda güvenilir ölçümler elde etmek için cihaz geliştiricileri şu yönergeleri izlemelidir:

• userdebug, root erişiminin etkinleştirildiği bir kullanıcı derlemesi olarak tanımlanır, ancak:
  • Yalnızca kullanıcı tarafından talep üzerine çalıştırılan, yalnızca kullanıcı hata ayıklaması içeren uygulamalar
  • Arka plan derlemeleri için dex2oatd karşı dex2oat kullanılması gibi yalnızca boşta bakım sırasında (şarj cihazında/tamamen şarjlı) çalışan işlemler
• Yapı türüne göre varsayılan olarak etkinleştirilen/devre dışı bırakılan özellikleri dahil etmeyin. Geliştiricilerin, hata ayıklama günlüğü veya yığın dökümü gibi pil ömrünü etkileyen herhangi bir günlük kaydı biçimini kullanmaları önerilmez.
• Userdebug'da varsayılan olarak etkinleştirilen tüm hata ayıklama özellikleri açıkça tanımlanmalı ve proje üzerinde çalışan tüm geliştiricilerle paylaşılmalıdır. Hata ayıklamaya çalıştığınız sorun çözülene kadar hata ayıklama özelliklerini yalnızca sınırlı bir süre için etkinleştirmelisiniz.

Derlemeyi kaynak bindirmeleri ile özelleştirme

Android derleme sistemi, oluşturma zamanında bir ürünü özelleştirmek için kaynak yer paylaşımlarını kullanır. Kaynak yer paylaşımları, varsayılanların üzerine uygulanan kaynak dosyalarını belirtir. Kaynak bindirmelerini kullanmak için proje yapı dosyasını değiştirerek PRODUCT_PACKAGE_OVERLAYS üst düzey dizininize göre bir yola ayarlayın. Derleme sistemi kaynakları aradığında bu yol, geçerli kökle birlikte aranan bir gölge kök haline gelir.

En sık özelleştirilmiş ayarlar , frameworks/base/core/res/res/values/config.xml dosyasında bulunur.

Bu dosyada bir kaynak yerleşimi ayarlamak için, aşağıdakilerden birini kullanarak kaplama dizinini proje derleme dosyasına ekleyin:

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

veya

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Ardından, dizine bir bindirme dosyası ekleyin, örneğin:

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

Bindirme config.xml dosyasında bulunan tüm dizeler veya dizi dizileri, orijinal dosyada bulunanların yerini alır.

bir ürün oluşturmak

Cihazınız için kaynak dosyaları birçok farklı şekilde düzenleyebilirsiniz. Burada, bir Pixel uygulamasını organize etmenin bir yolunun kısa bir açıklaması bulunmaktadır.

Pixel, marlin adlı bir ana cihaz yapılandırmasıyla uygulanır. Bu cihaz konfigürasyonundan, cihaz hakkında ad ve model gibi ürüne özgü bilgileri bildiren bir ürün tanımı makefile ile bir ürün oluşturulur. Tüm bunların nasıl kurulduğunu görmek için device/google/marlin dizinini görüntüleyebilirsiniz.

Ürün makefiles yazmak

Aşağıdaki adımlarda, ürün makefile'lerinin Pixel ürün grubuna benzer bir şekilde nasıl kurulacağı açıklanmaktadır:

1. Ürününüz için bir device/ <company-name> / <device-name> dizini oluşturun. Örneğin, device/google/marlin . Bu dizin, cihazınızın kaynak kodunu ve bunları oluşturmak için makefile dosyalarını içerecektir.
2. Aygıt için gereken dosyaları ve modülleri bildiren bir device.mk makefile oluşturun. Bir örnek için bkz. device/google/marlin/device-marlin.mk .
3. Cihaza dayalı olarak belirli bir ürün oluşturmak için bir ürün tanımı makefile oluşturun. Aşağıdaki makefile örnek olarak device/google/marlin/aosp_marlin.mk adresinden alınmıştır. device/google/marlin/device-marlin.mk ad vendor/google/marlin/device-vendor-marlin.mk marka, ve modeli.

   # 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
   

   Makefile'lerinize ekleyebileceğiniz ürüne özel ek değişkenler için bkz . Ürün tanımı değişkenlerini ayarlama .

4. Ürünün makefile dosyalarına işaret eden bir AndroidProducts.mk dosyası oluşturun. Bu örnekte, yalnızca ürün tanımı makefile gereklidir. Aşağıdaki örnek device/google/marlin/AndroidProducts.mk alınmıştır (hem marlin, Pixel'i hem de çoğu yapılandırmayı paylaşan yelken balığı Pixel XL'i içerir):

   PRODUCT_MAKEFILES := \
   	$(LOCAL_DIR)/aosp_marlin.mk \
   	$(LOCAL_DIR)/aosp_sailfish.mk
   
   COMMON_LUNCH_CHOICES := \
   	aosp_marlin-userdebug \
   	aosp_sailfish-userdebug
   

5. Panoya özel yapılandırmalar içeren bir BoardConfig.mk makefile oluşturun. Bir örnek için bkz. device/google/marlin/BoardConfig.mk .
6. Yalnızca Android 9 ve önceki sürümleri için , ürününüzü ("öğle yemeği kombinasyonu") yapıya bir tire ile ayrılmış bir yapı varyantı ile birlikte eklemek için bir vendorsetup.sh dosyası oluşturun. Örneğin:

   add_lunch_combo <product-name>-userdebug
   

7. Bu noktada aynı cihaz bazında daha fazla ürün çeşidi oluşturabilirsiniz.

Ürün tanımı değişkenlerini ayarlama

Ürüne özgü değişkenler, ürünün makefile dosyasında tanımlanır. Tablo, bir ürün tanım dosyasında tutulan bazı değişkenleri göstermektedir.

Varsayılan sistem dilini ve yerel ayar filtresini yapılandırma

Varsayılan dili ve sistem yerel ayar filtresini yapılandırmak için bu bilgileri kullanın, ardından yerel filtreyi yeni bir aygıt türü için etkinleştirin.

Özellikler

Özel sistem özelliklerini kullanarak hem varsayılan dili hem de sistem yerel filtresini yapılandırın:

• ro.product.locale : varsayılan yerel ayarı ayarlamak için. Bu, başlangıçta PRODUCT_LOCALES değişkenindeki ilk yerel ayara ayarlanmıştır; bu değeri geçersiz kılabilirsiniz. (Daha fazla bilgi için Ürün tanımı değişkenlerini ayarlama tablosuna bakın.)
• ro.localization.locale_filter : yerel adlara uygulanan bir normal ifade kullanarak bir yerel ayar filtresi ayarlamak için. Örneğin:
  • Kapsamlı filtre: ^(de-AT|de-DE|en|uk).* - yalnızca Almanca'ya (Avusturya ve Almanya varyantları), İngilizce'nin tüm İngilizce varyantlarına ve Ukraynaca'ya izin verir
  • Özel filtre: ^(?!de-IT|es).* - Almanca (İtalya varyantı) ve İspanyolca'nın tüm varyantları hariçtir.

Yerel ayar filtresini etkinleştirme

Filtreyi etkinleştirmek için ro.localization.locale_filter sistem özelliği dize değerini ayarlayın.

Fabrika kalibrasyonu sırasında oem/oem.prop aracılığıyla filtre özelliği değerini ve varsayılan dili ayarlayarak, filtreyi sistem görüntüsüne dönüştürmeden kısıtlamaları yapılandırabilirsiniz. Bu özellikleri aşağıda belirtildiği gibi PRODUCT_OEM_PROPERTIES değişkenine ekleyerek OEM bölümünden alınmasını sağlarsınız:

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

Daha sonra üretimde gerçek değerler, hedef gereksinimleri yansıtmak için oem/oem.prop yazılır. Bu yaklaşımla, fabrika ayarlarına sıfırlama sırasında varsayılan değerler korunur, böylece ilk ayarlar kullanıcıya tam olarak ilk kurulum gibi görünür.

ADB_VENDOR_KEYS USB üzerinden bağlanacak şekilde ayarlanıyor

ADB_VENDOR_KEYS ortam değişkeni, cihaz üreticilerinin manuel yetkilendirme olmadan adb üzerinden hata ayıklanabilir yapılara (-userdebug ve -eng, ancak -user değil) erişmesine olanak tanır. Normalde adb, her istemci bilgisayar için, bağlı herhangi bir cihaza göndereceği benzersiz bir RSA kimlik doğrulama anahtarı oluşturur. Bu, adb yetkilendirme iletişim kutusunda gösterilen RSA anahtarıdır. Alternatif olarak, bilinen anahtarları sistem görüntüsüne oluşturabilir ve bunları adb istemcisi ile paylaşabilirsiniz. Bu, adb yetkilendirme iletişim kutusuyla manuel olarak etkileşime girme ihtiyacını ortadan kaldırdığı için işletim sistemi geliştirme ve özellikle test etme için kullanışlıdır.

Satıcı anahtarları oluşturmak için bir kişi (genellikle bir sürüm yöneticisi) şunları yapmalıdır:

1. adb keygen kullanarak bir anahtar çifti oluşturun. Google cihazları için Google, her yeni işletim sistemi sürümü için yeni bir anahtar çifti oluşturur.
2. Anahtar çiftlerini kaynak ağacın herhangi bir yerinde kontrol edin. Google bunları örneğin, vendor/google/security/adb/ içinde depolar.
3. PRODUCT_ADB_KEYS yapı değişkenini anahtar dizininizi gösterecek şekilde ayarlayın. Google bunu, her işletim sistemi sürümü için yeni bir anahtar çifti oluşturmayı hatırlamamıza yardımcı olan PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub yazan anahtar dizinine bir Android.mk dosyası ekleyerek yapar.

Google'ın her sürüm için teslim edilmiş anahtar çiftlerimizi sakladığımız dizinde kullandığı makefile şöyledir:

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

Bu satıcı anahtarlarını kullanmak için, bir mühendisin yalnızca ADB_VENDOR_KEYS ortam değişkenini anahtar çiftlerinin depolandığı dizini gösterecek şekilde ayarlaması gerekir. Bu, adb manuel yetkilendirme gerektiren oluşturulan ana bilgisayar anahtarına geri dönmeden önce bu standart anahtarları denemesini söyler. adb yetkisiz bir cihaza bağlanamadığında, önceden ayarlanmamışsa, hata mesajı ADB_VENDOR_KEYS ayarlamanızı önerecektir.