Bu sayfa, Cloud Translation API ile çevrilmiştir.

Satıcı APEX

Alt düzey Android işletim sistemi modüllerini paketlemek ve yüklemek için APEX dosya biçimini kullanabilirsiniz. Yerel hizmetler ve kitaplıklar, HAL uygulamaları, ürün yazılımı, yapılandırma dosyaları vb. gibi bileşenlerin bağımsız olarak oluşturulmasına ve kurulumuna olanak tanır.

Satıcı APEX'leri, derleme sistemi tarafından otomatik olarak /vendor bölümüne yüklenir ve diğer bölümlerdeki APEX'ler gibi çalışma zamanında apexd tarafından etkinleştirilir.

Kullanım örnekleri

Satıcı görsellerinin modülerleştirilmesi

APEX'ler, satıcı görselleri üzerindeki özellik uygulamalarının doğal bir şekilde paketlenmesini ve modüler hale getirilmesini kolaylaştırır.

Satıcı görüntüleri, bağımsız olarak oluşturulmuş satıcı APEX'lerinin bir kombinasyonu olarak oluşturulduğunda, cihaz üreticileri, cihazlarında istenen belirli satıcı uygulamalarını kolayca seçip seçebilmektedir. Üreticiler, sağlanan APEX'lerden hiçbiri ihtiyaçlarına uygun değilse veya yepyeni bir özel donanıma sahipse, yeni bir satıcı APEX'i bile oluşturabilirler.

Örneğin, bir OEM, cihazını AOSP wifi uygulaması APEX, SoC bluetooth uygulaması APEX ve özel bir OEM telefon uygulaması APEX ile oluşturmayı seçebilir.

Satıcı APEX'leri olmadan, satıcı bileşenleri arasında çok fazla bağımlılığa sahip bir uygulama, dikkatli bir koordinasyon ve izleme gerektirir. Tüm bileşenlerin (yapılandırma dosyaları ve ekstra kitaplıklar dahil) özellikler arası iletişimin herhangi bir noktasında açıkça tanımlanmış arayüzlerle APEX'lere sarılmasıyla, farklı bileşenler birbiriyle değiştirilebilir hale gelir.

Geliştirici yinelemesi

Satıcı APEX'leri, geliştiricilerin satıcı modülleri geliştirirken Wi-Fi HAL gibi tüm özellik uygulamasını satıcı APEX'inde bir araya getirerek daha hızlı yineleme yapmasına yardımcı olur. Geliştiriciler daha sonra satıcı görüntüsünün tamamını yeniden oluşturmak yerine, değişiklikleri test etmek için satıcı APEX'ini oluşturabilir ve ayrı ayrı gönderebilir.

Bu, öncelikli olarak tek bir özellik alanında çalışan ve yalnızca bu özellik alanında yineleme yapmak isteyen geliştiriciler için geliştirici yineleme döngüsünü basitleştirir ve hızlandırır.

Bir özellik alanının bir APEX'te doğal olarak paketlenmesi aynı zamanda o özellik alanı için değişikliklerin oluşturulması, iletilmesi ve test edilmesi sürecini de basitleştirir. Örneğin, bir APEX'in yeniden yüklenmesi, APEX'in içerdiği paket kitaplık veya yapılandırma dosyalarını otomatik olarak günceller.

Bir özellik alanının bir APEX'te paketlenmesi aynı zamanda kötü cihaz davranışı gözlemlendiğinde hata ayıklamayı veya geri dönmeyi de kolaylaştırır. Örneğin, telefon yeni bir yapıda kötü çalışıyorsa, geliştiriciler eski bir telefon uygulaması APEX'ini bir cihaza yüklemeyi deneyebilir (tam yapıyı flashlamaya gerek kalmadan) ve iyi davranışın geri gelip gelmediğini görebilirler.

Örnek iş akışı:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

Örnekler

Temel bilgiler

Cihaz gereksinimleri, dosya formatı ayrıntıları ve kurulum adımları da dahil olmak üzere genel APEX bilgileri için ana APEX Dosya Formatı sayfasına bakın.

Android.bp , vendor: true özelliğinin ayarlanması, bir APEX modülünü satıcı APEX'i yapar.

apex {
  ..
  vendor: true,
  ..
}

İkili dosyalar ve paylaşılan kitaplıklar

Bir APEX, kararlı arayüzlere sahip olmadıkları sürece APEX verisi içinde geçişli bağımlılıklar içerir.

Satıcı APEX bağımlılıklarına yönelik kararlı yerel arayüzler arasında stubs cc_library , ndk_library veya llndk_library bulunur. Bu bağımlılıklar paketlemenin dışında bırakılır ve bağımlılıklar APEX bildirimine kaydedilir. Bildirim, harici yerel bağımlılıkların çalışma zamanında mevcut olması için linkerconfig tarafından işlenir.

/system bölümündeki APEX'lerden farklı olarak satıcı APEX'leri genellikle belirli bir VNDK sürümüne bağlıdır. VNDK kitaplıkları, sürüm içinde ABI kararlılığını garanti eder, böylece VNDK kitaplıklarını kararlı olarak değerlendirebilir ve use_vndk_as_stable özelliğini kullanarak satıcı APEX'lerini APEX'lerden hariç tutarak bunların boyutunu azaltabiliriz.

Aşağıdaki kod parçasında APEX, hem ikili dosyayı ( my_service ) hem de onun kararlı olmayan bağımlılıklarını ( *.so dosyaları) içerecektir. my_service libbase gibi VNDK kitaplıklarıyla oluşturulmuş olsa bile VNDK kitaplıklarını içermeyecektir. Bunun yerine, çalışma zamanında my_service sistem tarafından sağlanan VNDK kitaplıklarından libbase kullanacaktır.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

Aşağıdaki kod parçasında APEX, my_standalone_lib paylaşılan kütüphanesini ve onun stabil olmayan bağımlılıklarından herhangi birini (yukarıda açıklandığı gibi) içerecektir.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

HAL uygulamaları

Bir HAL uygulamasını tanımlamak için aşağıdaki örneklere benzer şekilde satıcı APEX'inde karşılık gelen ikili dosyaları ve kitaplıkları sağlayın:

HAL uygulamasını tam olarak kapsamak için APEX'in ayrıca ilgili VINTF parçalarını ve başlatma komut dosyalarını da belirtmesi gerekir.

VINTF parçaları

VINTF parçaları, parçalar APEX'in etc/vintf dosyasında bulunduğunda satıcı APEX'ten sunulabilir.

VINTF parçalarını APEX'e gömmek için prebuilts özelliğini kullanın.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

Komut dosyalarını başlat

APEX'ler başlatma komut dosyalarını iki şekilde içerebilir: (A) APEX verisi içindeki önceden oluşturulmuş bir metin dosyası veya (B) /vendor/etc içindeki normal bir başlatma komut dosyası. Her ikisini de aynı APEX için ayarlayabilirsiniz.

APEX'te komut dosyasını başlatın:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

APEX'lerdeki başlatma komut dosyaları yalnızca service tanımlarına sahip olabilir. Satıcı APEX'lerindeki başlatma komut dosyaları da on <property> yönergelerine sahip olabilir.

on direktiflerini kullanırken dikkatli olun. APEX'lerdeki başlatma komut dosyaları APEX'ler etkinleştirildikten sonra ayrıştırılıp yürütüldüğünden, bazı olaylar veya özellikler kullanılamaz. Eylemleri mümkün olduğu kadar erken başlatmak için apex.all.ready=true seçeneğini kullanın.

Firmware

Örnek:

Vibratör servis yazılımı

Firmware'i, prebuilt_firmware modül türüyle satıcının APEX'ine aşağıdaki gibi ekleyin.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

prebuilt_firmware modülleri APEX'in <apex name>/etc/firmware dizinine kurulur. ueventd firmware modüllerini bulmak için /apex/*/etc/firmware dizinlerini tarar.

APEX'in file_contexts , bu dosyalara çalışma zamanında ueventd tarafından erişilebildiğinden emin olmak için tüm bellenim veri yükü girişlerini doğru şekilde etiketlemelidir; genellikle vendor_file etiketi yeterlidir. Örneğin:

(/.*)? u:object_r:vendor_file:s0

Çekirdek modülleri

Çekirdek modüllerini satıcının APEX'ine önceden oluşturulmuş modüller olarak aşağıdaki gibi gömün.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

APEX'in file_contexts , çekirdek modülü veri yükü girişlerini doğru şekilde etiketlemelidir. Örneğin:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

Çekirdek modülleri açıkça kurulmalıdır. Satıcı bölümündeki aşağıdaki örnek başlatma komut dosyası, insmod aracılığıyla kurulumu gösterir:

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

Çalışma zamanı kaynak katmanları

Örnek:

Mürekkep balığı RRO'ları

rros özelliğini kullanarak çalışma zamanı kaynak katmanlarını satıcı APEX'ine gömün.

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

Diğer yapılandırma dosyaları

Satıcı APEX'leri, satıcı APEX'lerinin içinde önceden oluşturulmuş olarak genellikle satıcı bölümünde bulunan çeşitli diğer yapılandırma dosyalarını destekler ve daha fazlası eklenmektedir.

Örnekler:

Özellik bildirimi XML'leri
- Sensörler , bir sensör HAL satıcısı APEX'te önceden oluşturulmuş XML'ler içerir
Yapılandırma dosyalarını girin
- Dokunmatik ekran , yalnızca yapılandırma sağlayıcısı APEX'te önceden oluşturulmuş olarak yapılandırılır

Ekstra geliştirme özellikleri

Açılışta APEX seçimi

Örnek:

Mürekkepbalığı Taklit Kamera HAL APEX

Geliştiriciler ayrıca aynı APEX adını ve anahtarını paylaşan satıcı APEX'lerinin birden fazla sürümünü yükleyebilir ve ardından kalıcı sysprop'ları kullanarak her önyükleme sırasında hangi sürümün etkinleştirileceğini seçebilir. Belirli geliştirici kullanım durumları için bu, adb install kullanarak APEX'in yeni bir kopyasını yüklemekten daha basit olabilir.

Örnek kullanım durumları:

Wi-Fi HAL satıcısı APEX'in 3 sürümünü yükleyin: Kalite Güvence ekipleri bir sürümü kullanarak manuel veya otomatik testler gerçekleştirebilir, ardından başka bir sürümü yeniden başlatıp testleri yeniden çalıştırabilir ve ardından nihai sonuçları karşılaştırabilir.
Kamera HAL satıcısı APEX'in güncel ve deneysel 2 sürümünü yükleyin: Test sürümünü kullananlar, ek bir dosya indirip yüklemeden deneysel sürümü kullanabilir, böylece kolayca geri değiştirebilirler.

Önyükleme sırasında apexd , doğru APEX sürümünü etkinleştirmek için belirli bir formatı izleyen sysprop'ları arar.

Özellik anahtarı için beklenen formatlar şunlardır:

Önyükleme yapılandırması
- BoardConfig.mk varsayılan değeri ayarlamak için kullanılır.
- androidboot.vendor.apex.<apex name>
Kalıcı sistem prop
- Zaten önyüklenmiş bir cihazda ayarlanan varsayılan değeri değiştirmek için kullanılır.
- Varsa bootconfig değerini geçersiz kılar.
- persist.vendor.apex.<apex name>

Özelliğin değeri, etkinleştirilmesi gereken APEX'in dosya adı olmalıdır.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

Varsayılan sürüm aynı zamanda BoardConfig.mk dosyasındaki bootconfig kullanılarak da yapılandırılmalıdır:

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

Cihaz başlatıldıktan sonra kalıcı sysprop'u ayarlayarak etkinleştirilmiş sürümü değiştirin:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

Cihaz, flashlamadan sonra bootconfig'in güncellenmesini destekliyorsa (örneğin, fastboot oem komutları yoluyla), çoklu kurulu APEX için bootconfig özelliğinin değiştirilmesi, açılışta etkinleştirilen sürümü de değiştirir.

Mürekkepbalığı tabanlı sanal referans cihazları için, başlatma sırasında bootconfig özelliğini doğrudan ayarlamak için --extra_bootconfig_args komutunu kullanabilirsiniz. Örneğin:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";

Satıcı APEX'leri, derleme sistemi tarafından otomatik olarak /vendor bölümüne yüklenir ve diğer bölümlerdeki APEX'ler gibi çalışma zamanında apexd tarafından etkinleştirilir.

Kullanım örnekleri

Satıcı görsellerinin modülerleştirilmesi

APEX'ler, satıcı görselleri üzerindeki özellik uygulamalarının doğal bir şekilde paketlenmesini ve modüler hale getirilmesini kolaylaştırır.

Örneğin, bir OEM, cihazını AOSP wifi uygulaması APEX, SoC bluetooth uygulaması APEX ve özel bir OEM telefon uygulaması APEX ile oluşturmayı seçebilir.

Geliştirici yinelemesi

Örnek iş akışı:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

Örnekler

Temel bilgiler

Cihaz gereksinimleri, dosya formatı ayrıntıları ve kurulum adımları da dahil olmak üzere genel APEX bilgileri için ana APEX Dosya Formatı sayfasına bakın.

Android.bp , vendor: true özelliğinin ayarlanması, bir APEX modülünü satıcı APEX'i yapar.

apex {
  ..
  vendor: true,
  ..
}

İkili dosyalar ve paylaşılan kitaplıklar

Bir APEX, kararlı arayüzlere sahip olmadıkları sürece APEX verisi içinde geçişli bağımlılıklar içerir.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

Aşağıdaki kod parçasında APEX, my_standalone_lib paylaşılan kütüphanesini ve onun stabil olmayan bağımlılıklarından herhangi birini (yukarıda açıklandığı gibi) içerecektir.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

HAL uygulamaları

Bir HAL uygulamasını tanımlamak için aşağıdaki örneklere benzer şekilde satıcı APEX'inde karşılık gelen ikili dosyaları ve kitaplıkları sağlayın:

HAL uygulamasını tam olarak kapsamak için APEX'in ayrıca ilgili VINTF parçalarını ve başlatma komut dosyalarını da belirtmesi gerekir.

VINTF parçaları

VINTF parçaları, parçalar APEX'in etc/vintf dosyasında bulunduğunda satıcı APEX'ten sunulabilir.

VINTF parçalarını APEX'e gömmek için prebuilts özelliğini kullanın.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

Komut dosyalarını başlat

APEX'te komut dosyasını başlatın:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

APEX'lerdeki başlatma komut dosyaları yalnızca service tanımlarına sahip olabilir. Satıcı APEX'lerindeki başlatma komut dosyaları da on <property> yönergelerine sahip olabilir.

Firmware

Örnek:

Vibratör servis yazılımı

Firmware'i, prebuilt_firmware modül türüyle satıcının APEX'ine aşağıdaki gibi ekleyin.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

prebuilt_firmware modülleri APEX'in <apex name>/etc/firmware dizinine kurulur. ueventd firmware modüllerini bulmak için /apex/*/etc/firmware dizinlerini tarar.

(/.*)? u:object_r:vendor_file:s0

Çekirdek modülleri

Çekirdek modüllerini satıcının APEX'ine önceden oluşturulmuş modüller olarak aşağıdaki gibi gömün.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

APEX'in file_contexts , çekirdek modülü veri yükü girişlerini doğru şekilde etiketlemelidir. Örneğin:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

Çekirdek modülleri açıkça kurulmalıdır. Satıcı bölümündeki aşağıdaki örnek başlatma komut dosyası, insmod aracılığıyla kurulumu gösterir:

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

Çalışma zamanı kaynak katmanları

Örnek:

Mürekkep balığı RRO'ları

rros özelliğini kullanarak çalışma zamanı kaynak katmanlarını satıcı APEX'ine gömün.

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

Diğer yapılandırma dosyaları

Örnekler:

Özellik bildirimi XML'leri
- Sensörler , bir sensör HAL satıcısı APEX'te önceden oluşturulmuş XML'ler içerir
Yapılandırma dosyalarını girin
- Dokunmatik ekran , yalnızca yapılandırma sağlayıcısı APEX'te önceden oluşturulmuş olarak yapılandırılır

Ekstra geliştirme özellikleri

Açılışta APEX seçimi

Örnek:

Mürekkepbalığı Taklit Kamera HAL APEX

Geliştiriciler ayrıca aynı APEX adını ve anahtarını paylaşan satıcı APEX'lerinin birden fazla sürümünü yükleyebilir ve ardından kalıcı sysprop'ları kullanarak her önyükleme sırasında hangi sürümün etkinleştirileceğini seçebilir. Bazı geliştirici kullanım durumları için bu, adb install kullanarak APEX'in yeni bir kopyasını yüklemekten daha basit olabilir.

Örnek kullanım durumları:

Wi-Fi HAL satıcısı APEX'in 3 sürümünü yükleyin: Kalite Güvence ekipleri bir sürümü kullanarak manuel veya otomatik testler gerçekleştirebilir, ardından başka bir sürümü yeniden başlatıp testleri yeniden çalıştırabilir ve ardından nihai sonuçları karşılaştırabilir.
Kamera HAL satıcısı APEX'in güncel ve deneysel 2 sürümünü yükleyin: Test sürümünü kullananlar, ek bir dosya indirip yüklemeden deneysel sürümü kullanabilir, böylece kolayca geri değiştirebilirler.

Önyükleme sırasında apexd , doğru APEX sürümünü etkinleştirmek için belirli bir formatı izleyen sysprop'ları arar.

Özellik anahtarı için beklenen formatlar şunlardır:

Önyükleme yapılandırması
- BoardConfig.mk varsayılan değeri ayarlamak için kullanılır.
- androidboot.vendor.apex.<apex name>
Kalıcı sistem prop
- Zaten önyüklenmiş bir cihazda ayarlanan varsayılan değeri değiştirmek için kullanılır.
- Varsa bootconfig değerini geçersiz kılar.
- persist.vendor.apex.<apex name>

Özelliğin değeri, etkinleştirilmesi gereken APEX'in dosya adı olmalıdır.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

Varsayılan sürüm aynı zamanda BoardConfig.mk dosyasındaki bootconfig kullanılarak da yapılandırılmalıdır:

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

Cihaz başlatıldıktan sonra kalıcı sysprop'u ayarlayarak etkinleştirilmiş sürümü değiştirin:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

Mürekkepbalığı tabanlı sanal referans cihazları için, başlatma sırasında bootconfig özelliğini doğrudan ayarlamak için --extra_bootconfig_args komutunu kullanabilirsiniz. Örneğin:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";

Satıcı APEX'leri, derleme sistemi tarafından otomatik olarak /vendor bölümüne yüklenir ve diğer bölümlerdeki APEX'ler gibi çalışma zamanında apexd tarafından etkinleştirilir.

Kullanım örnekleri

Satıcı görsellerinin modülerleştirilmesi

APEX'ler, satıcı görselleri üzerindeki özellik uygulamalarının doğal bir şekilde paketlenmesini ve modüler hale getirilmesini kolaylaştırır.

Örneğin, bir OEM, cihazını AOSP wifi uygulaması APEX, SoC bluetooth uygulaması APEX ve özel bir OEM telefon uygulaması APEX ile oluşturmayı seçebilir.

Geliştirici yinelemesi

Örnek iş akışı:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

Örnekler

Temel bilgiler

Cihaz gereksinimleri, dosya formatı ayrıntıları ve kurulum adımları da dahil olmak üzere genel APEX bilgileri için ana APEX Dosya Formatı sayfasına bakın.

Android.bp , vendor: true özelliğinin ayarlanması, bir APEX modülünü satıcı APEX'i yapar.

apex {
  ..
  vendor: true,
  ..
}

İkili dosyalar ve paylaşılan kitaplıklar

Bir APEX, kararlı arayüzlere sahip olmadıkları sürece APEX verisi içinde geçişli bağımlılıklar içerir.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

Aşağıdaki kod parçasında APEX, my_standalone_lib paylaşılan kütüphanesini ve onun stabil olmayan bağımlılıklarından herhangi birini (yukarıda açıklandığı gibi) içerecektir.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

HAL uygulamaları

Bir HAL uygulamasını tanımlamak için aşağıdaki örneklere benzer şekilde satıcı APEX'inde karşılık gelen ikili dosyaları ve kitaplıkları sağlayın:

HAL uygulamasını tam olarak kapsamak için APEX'in ayrıca ilgili VINTF parçalarını ve başlatma komut dosyalarını da belirtmesi gerekir.

VINTF parçaları

VINTF parçaları, parçalar APEX'in etc/vintf dosyasında bulunduğunda satıcı APEX'ten sunulabilir.

VINTF parçalarını APEX'e gömmek için prebuilts özelliğini kullanın.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

Komut dosyalarını başlat

APEX'te komut dosyasını başlatın:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

APEX'lerdeki başlatma komut dosyaları yalnızca service tanımlarına sahip olabilir. Satıcı APEX'lerindeki başlatma komut dosyaları da on <property> yönergelerine sahip olabilir.

Firmware

Örnek:

Vibratör servis yazılımı

Firmware'i, prebuilt_firmware modül türüyle satıcının APEX'ine aşağıdaki gibi ekleyin.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

prebuilt_firmware modülleri APEX'in <apex name>/etc/firmware dizinine kurulur. ueventd firmware modüllerini bulmak için /apex/*/etc/firmware dizinlerini tarar.

(/.*)? u:object_r:vendor_file:s0

Çekirdek modülleri

Çekirdek modüllerini satıcının APEX'ine önceden oluşturulmuş modüller olarak aşağıdaki gibi gömün.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

APEX'in file_contexts , çekirdek modülü veri yükü girişlerini doğru şekilde etiketlemelidir. Örneğin:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

Çekirdek modülleri açıkça kurulmalıdır. Satıcı bölümündeki aşağıdaki örnek başlatma komut dosyası, insmod aracılığıyla kurulumu gösterir:

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

Çalışma zamanı kaynak katmanları

Örnek:

Mürekkep balığı RRO'ları

rros özelliğini kullanarak çalışma zamanı kaynak katmanlarını satıcı APEX'ine gömün.

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

Diğer yapılandırma dosyaları

Örnekler:

Özellik bildirimi XML'leri
- Sensörler , bir sensör HAL satıcısı APEX'te önceden oluşturulmuş XML'ler içerir
Yapılandırma dosyalarını girin
- Dokunmatik ekran , yalnızca yapılandırma sağlayıcısı APEX'te önceden oluşturulmuş olarak yapılandırılır

Ekstra geliştirme özellikleri

Açılışta APEX seçimi

Örnek:

Mürekkepbalığı Taklit Kamera HAL APEX

Örnek kullanım durumları:

Wi-Fi HAL satıcısı APEX'in 3 sürümünü yükleyin: Kalite Güvence ekipleri bir sürümü kullanarak manuel veya otomatik testler gerçekleştirebilir, ardından başka bir sürümü yeniden başlatıp testleri yeniden çalıştırabilir ve ardından nihai sonuçları karşılaştırabilir.
Kamera HAL satıcısı APEX'in güncel ve deneysel 2 sürümünü yükleyin: Test sürümünü kullananlar, ek bir dosya indirip yüklemeden deneysel sürümü kullanabilir, böylece kolayca geri değiştirebilirler.

Önyükleme sırasında apexd , doğru APEX sürümünü etkinleştirmek için belirli bir formatı izleyen sysprop'ları arar.

Özellik anahtarı için beklenen formatlar şunlardır:

Önyükleme yapılandırması
- BoardConfig.mk varsayılan değeri ayarlamak için kullanılır.
- androidboot.vendor.apex.<apex name>
Kalıcı sistem prop
- Zaten önyüklenmiş bir cihazda ayarlanan varsayılan değeri değiştirmek için kullanılır.
- Varsa bootconfig değerini geçersiz kılar.
- persist.vendor.apex.<apex name>

Özelliğin değeri, etkinleştirilmesi gereken APEX'in dosya adı olmalıdır.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

Varsayılan sürüm aynı zamanda BoardConfig.mk dosyasındaki bootconfig kullanılarak da yapılandırılmalıdır:

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

Cihaz başlatıldıktan sonra kalıcı sysprop'u ayarlayarak etkinleştirilmiş sürümü değiştirin:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

Cihaz, flashlamadan sonra bootconfig'in güncellenmesini destekliyorsa (örneğin, fastboot oem komutları aracılığıyla), çoklu kurulu APEX için bootconfig özelliğinin değiştirilmesi, açılışta etkinleştirilen sürümü de değiştirir.

Mürekkepbalığı tabanlı sanal referans cihazları için, başlatma sırasında bootconfig özelliğini doğrudan ayarlamak için --extra_bootconfig_args komutunu kullanabilirsiniz. Örneğin:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";