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:
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:
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:
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";
, 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:
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:
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:
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;
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";
, 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:
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:
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:
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ı 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";