Yeni cihaz ekleme

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

Her yeni Android modülünde, derleme sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendiren bir yapılandırma dosyası bulunmalıdır. Android, Soong derleme sistemini kullanır. Android derleme sistemi hakkında daha fazla bilgi için Android'i Derleme başlıklı makaleye bakın.

Derleme katmanlarını anlama

Derleme 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, üstündeki katmanla bire çok ilişkilidir. Örneğin, bir mimaride birden fazla pano olabilir ve her panoda birden fazla ürün bulunabilir. Belirli bir katmandaki bir öğeyi aynı katmandaki bir öğenin uzmanlık alanı olarak tanımlayabilirsiniz. Bu sayede kopyalama işlemi ortadan kalkar ve bakım kolaylaşır.

Derleme varyantlarını kullanma

Belirli bir ürün için derleme yaparken nihai sürüm derlemesinde küçük değişiklikler yapmak faydalıdır. Bir modül tanımında modül, LOCAL_MODULE_TAGS ile etiketler belirtebilir. Bu etiketler optional (varsayılan), debug ve eng değerlerinden biri veya daha fazlası olabilir.

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

Bunlar, şu anda tanımlanmış derleme çeşitleridir.

Userdebug ile ilgili yönergeler

Test aşamasında userdebug derlemeleri ç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 derlemeleri arasında tutarlılık sağlamak ve hata ayıklama için kullanılan derlemelerde güvenilir metrikler elde etmek amacıyla cihaz geliştiricilerin aşağıdaki yönergelere uyması gerekir:

• userdebug, aşağıdakiler hariç olmak üzere kök erişimi etkinleştirilmiş bir kullanıcı derlemesi olarak tanımlanır:
  • Yalnızca kullanıcı tarafından talep edildiğinde çalıştırılan, yalnızca kullanıcı hata ayıklama uygulamaları
  • Yalnızca boşta kalma bakımı sırasında (şarj cihazına bağlıyken/tamamen şarj edilmişken) çalışan işlemler (ör. arka planda derleme için dex2oatd yerine dex2oat kullanma)
• Derleme 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 kullanması önerilmez.
• Userdebug'da varsayılan olarak etkinleştirilen tüm hata ayıklama özellikleri net bir şekilde tanımlanmalı ve proje üzerinde çalışan tüm geliştiricilerle paylaşılmalıdır. Hata ayıklama özelliklerini yalnızca hata ayıklamaya çalıştığınız sorun çözülene kadar sınırlı bir süre için etkinleştirmeniz gerekir.

Kaynak katmanlarıyla derlemeyi özelleştirme

Android derleme sistemi, derleme sırası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 yer paylaşımlarını kullanmak için proje derleme dosyasını değiştirerek PRODUCT_PACKAGE_OVERLAYS öğesini en üst düzey dizininize göre göreli bir yola ayarlayın. Bu yol, derleme sistemi kaynak ararken mevcut kökle birlikte aranan bir gölge kök haline gelir.

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

Bu dosyada kaynak yerleşimi ayarlamak için aşağıdaki yöntemlerden birini kullanarak yerleşim 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 yer paylaşımı dosyası ekleyin. Örneğin:

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

Yer paylaşımı config.xml dosyasında bulunan dizeler veya dize dizileri, orijinal dosyada bulunanların yerini alır.

Ürün geliştirme

Cihazınızdaki kaynak dosyaları birçok farklı şekilde düzenleyebilirsiniz. Pixel uygulamasını düzenlemenin bir yoluyla ilgili kısa bir açıklama aşağıda verilmiştir.

Pixel, marlin adlı ana cihaz yapılandırmasıyla uygulanır. Bu cihaz yapılandırmasından, cihazla ilgili ürüne özel bilgileri (ör. ad ve model) bildiren bir ürün tanımı makefile'ı içeren bir ürün oluşturulur. Tüm bunların nasıl ayarlandığını görmek için device/google/marlindizinidevice/google/marlin görüntüleyebilirsiniz.

Ürün makefile'ları yazma

Aşağıdaki adımlarda, ürün makefile'larının Pixel ürün serisine benzer şekilde nasıl ayarlanacağı açıklanmaktadır:

1. Ürününüz için device/<company-name>/<device-name> dizin oluşturun. Örneğin, device/google/marlin. Bu dizinde, cihazınızın kaynak kodu ve bunları oluşturmak için kullanılan makefile'lar yer alır.
2. Cihaz için gereken dosyaları ve modülleri bildiren bir device.mkmakefile oluşturun. Örnek için device/google/marlin/device-marlin.mk bölümüne bakın.
3. Cihaza göre belirli bir ürün oluşturmak için ürün tanımı makefile'ı oluşturun. Aşağıdaki makefile, örnek olarak device/google/marlin/aosp_marlin.mk kaynağından alınmıştır. Ürünün, makefile aracılığıyla device/google/marlin/device-marlin.mk ve vendor/google/marlin/device-vendor-marlin.mk dosyalarından devralındığını, aynı zamanda ad, marka ve model gibi ürüne özel bilgileri de bildirdiğini unutmayın.

   # 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'larınıza ekleyebileceğiniz diğer ürüne özel değişkenler için Ürün tanımı değişkenlerini ayarlama başlıklı makaleyi inceleyin.

4. Ürünün makefile'ları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'den (yapılandırmanın büyük bir bölümünü paylaşan Pixel olan marlin ve Pixel XL olan sailfish'i içerir) alınmıştır:

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

5. Kartla ilgili yapılandırmaları içeren bir BoardConfig.mk makefile oluşturun. Örnek için device/google/marlin/BoardConfig.mk bölümüne bakın.
6. Yalnızca Android 9 ve önceki sürümlerde, ürününüzü (ör. "öğle yemeği menüsü") tireyle ayrılmış bir derleme varyantıyla birlikte derlemeye eklemek için bir vendorsetup.sh dosyası oluşturun. Örneğin:

   add_lunch_combo <product-name>-userdebug
   

7. Bu noktada, aynı cihaza dayalı daha fazla ürün varyantı oluşturabilirsiniz.

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

Ürüne özel değişkenler, ürünün makefile dosyasında tanımlanır. Tabloda, ürün tanımı dosyasında tutulan değişkenlerden bazıları gösterilmektedir.

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 yeni bir cihaz türü için yerel ayar filtresini etkinleştirin.

Özellikler

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

• ro.product.locale: Varsayılan yerel ayarı belirlemek için. Bu değer başlangıçta PRODUCT_LOCALES değişkenindeki ilk yerel ayara ayarlanı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 ayar adı için normal ifade uygulayarak yerel ayar filtresi ayarlamak için. Örneğin:
  • Kapsayıcı filtre: ^(de-AT|de-DE|en|uk).* - Yalnızca Almanca (Avusturya ve Almanya varyantları), İngilizce'nin tüm İngilizce varyantları ve Ukraynaca'ya izin verir.
  • Hariç tutma filtresi: ^(?!de-IT|es).* - Almanca'yı (İtalya varyantı) ve İspanyolca'nın tüm varyantlarını hariç tutar.

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 yerleştirmeden kısıtlamaları yapılandırabilirsiniz. Bu özellikleri aşağıdaki gibi PRODUCT_OEM_PROPERTIES değişkenine ekleyerek OEM bölümünden alındığından emin olursunuz:

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

Ardından, hedef gereksinimlerini yansıtmak için üretimde gerçek değerler oem/oem.prop'ya yazılır. Bu yaklaşımla, fabrika ayarlarına sıfırlama sırasında varsayılan değerler korunur. Bu nedenle, ilk ayarlar kullanıcıya ilk kurulum gibi görünür.

USB üzerinden bağlanmak için ADB_VENDOR_KEYS'i ayarlayın

ADB_VENDOR_KEYS ortam değişkeni, cihaz üreticilerinin manuel yetkilendirme olmadan adb üzerinden hata ayıklanabilir derlemelere (-userdebug ve -eng, ancak -user değil) erişmesini sağlar. Normalde adb, her istemci bilgisayar için benzersiz bir RSA kimlik doğrulama anahtarı oluşturur ve bunu bağlı tüm cihazlara gönderir. Bu, adb yetkilendirme iletişim kutusunda gösterilen RSA anahtarıdır. Alternatif olarak, bilinen anahtarları sistem görüntüsüne yerleştirebilir ve adb istemcisiyle paylaşabilirsiniz. Bu, işletim sistemi geliştirme ve özellikle test için yararlıdır. Çünkü adb yetkilendirme iletişim kutusuyla manuel olarak etkileşim kurma ihtiyacını ortadan kaldırır.

Tedarikçi anahtarları oluşturmak için bir kişinin (genellikle sürüm yöneticisi) şunları yapması gerekir:

1. adb keygen kullanarak anahtar çifti oluşturun. Google cihazlar için Google, her yeni işletim sistemi sürümünde yeni bir anahtar çifti oluşturur.
2. Anahtar çiftlerini kaynak ağacında bir yerde kontrol edin. Google bunları örneğin vendor/google/security/adb/ konumunda saklar.
3. Derleme değişkeni PRODUCT_ADB_KEYS'yı anahtar dizininizi işaret edecek şekilde ayarlayın. Google, anahtar dizinine Android.mk dosyası ekleyerek bunu yapar. Bu dosya, PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub ifadesini içerir ve her işletim sistemi sürümü için yeni bir anahtar çifti oluşturmayı unutmamamızı sağlar.

Google'ın her sürüm için kontrol edilen anahtar çiftlerimizi depoladığımız dizinde kullandığı makefile şudur:

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 mühendisin yalnızca ADB_VENDOR_KEYS ortam değişkenini, anahtar çiftlerinin depolandığı dizine yönlendirmesi gerekir. Bu, adb'ya, manuel yetkilendirme gerektiren oluşturulmuş ana bilgisayar anahtarına geri dönmeden önce bu standart anahtarları denemesini söyler. adb yetkisiz bir cihaza bağlanamadığında hata mesajında, ADB_VENDOR_KEYS ayarlanmamışsa ayarlamanız önerilir.