Saat Dilimi Kuralları

Android 10, APK tabanlı saat dilimi veri güncelleme mekanizmasını (Android 8.1 ve Android 9'da mevcuttur) kullanımdan kaldırır ve onu APEX tabanlı modül güncelleme mekanizmasıyla değiştirir. AOSP 8.1 ila 13, OEM'lerin APK tabanlı güncellemeleri etkinleştirmesi için gereken platform kodunu hala içerir, böylece Android 10'a yükseltme yapan cihazlar, APK aracılığıyla iş ortağı tarafından sağlanan saat dilimi veri güncellemelerini almaya devam edebilir. Ancak, APK tabanlı bir güncelleme APEX tabanlı bir güncellemenin yerini aldığından (yani APK güncellemesi alan bir cihaz APEX tabanlı güncellemeleri yok sayacağından) modül güncellemelerini de alan bir üretim cihazında APK güncelleme mekanizması kullanılmamalıdır. ).

Saat dilimi güncellemeleri (Android 10+)

Android 10 ve sonraki sürümlerde desteklenen Saat Dilimi Verileri modülü, Android cihazlarda yaz saatini (DST) ve saat dilimlerini güncelleyerek dini, siyasi ve jeopolitik nedenlerle sık sık değişebilen verileri standart hale getirir.

Güncellemeler aşağıdaki süreci kullanır:

1. IANA , Saat Dilimi Veritabanı için bir güncelleme yayınladı Bir veya daha fazla hükümetin kendi ülkelerinde bir saat dilimi kuralını değiştirmesine yanıt olarak bir güncelleme yayınladı.
2. Google veya Android iş ortağı, güncellenmiş saat dilimlerini içeren bir Saat Dilimi Veri modülü güncellemesi (APEX dosyası) hazırlar.
3. Son kullanıcı cihazı güncellemeyi indirir, yeniden başlatır, ardından değişiklikleri uygular, ardından cihazın saat dilimi verileri güncellemeden yeni saat dilimi verilerini içerir.

Modüllerle ilgili ayrıntılar için, bkz. Modüler Sistem Bileşenleri .

Saat dilimi güncellemeleri (Android 8.1–9)

Not: APK tabanlı saat dilimi veri güncelleme mekanizması özelliği, Android U'dan itibaren tamamen kaldırılmıştır ve kaynak kodunda bulunamaz. İş ortakları, Time Zone Mainline modülüne tamamen geçiş yapmalıdır.

Android 8.1 ve Android 9'da OEM'ler, güncellenmiş saat dilimi kuralları verilerini bir sistem güncellemesi gerektirmeden cihazlara göndermek için APK tabanlı bir mekanizma kullanabilir. Bu mekanizma, kullanıcıların güncellemeleri zamanında almalarını sağlar (böylece bir Android cihazının kullanım ömrünü uzatır) ve Android ortaklarının sistem görüntüsü güncellemelerinden bağımsız olarak saat dilimi güncellemelerini test etmelerini sağlar.

Android çekirdek kitaplıkları ekibi, stok Android cihazında saat dilimi kurallarını güncellemek için gerekli veri dosyalarını sağlar. OEM'ler, cihazları için saat dilimi güncellemeleri oluştururken bu veri dosyalarını kullanmayı seçebilir veya tercih edilirse kendi veri dosyalarını oluşturabilir. Her durumda, OEM'ler, desteklenen cihazları için kalite güvencesi/testi, zamanlaması ve saat dilimi kuralı güncellemelerinin başlatılması üzerindeki kontrolü elinde tutar.

Android saat dilimi kaynak kodu ve verileri

Tüm stok Android cihazları, bu özelliği kullanmayanlar bile, saat dilimi kuralları verilerine ihtiyaç duyar ve /system bölümünde varsayılan bir saat dilimi kuralı verileri kümesiyle gönderilmelidir. Bu veriler daha sonra Android kaynak ağacındaki aşağıdaki kitaplıklardan gelen kod tarafından kullanılır:

• libcore/ 'dan yönetilen kod (örneğin, java.util.TimeZone ) tzdata ve tzlookup.xml dosyalarını kullanır.
• bionic/ içindeki yerel kitaplık kodu (örneğin, mktime , localtime sistem çağrıları için) tzdata dosyasını kullanır.
• external/icu/ /icu/ içindeki ICU4J/ICU4C kitaplık kodu, icu .dat dosyasını kullanır.

Bu kitaplıklar /data/misc/zoneinfo/current dizininde bulunabilecek bindirme dosyalarının kaydını tutar. Bindirme dosyalarının, geliştirilmiş saat dilimi kuralları verilerini içermesi ve böylece cihazların /system değiştirilmeden güncellenmesine olanak sağlaması beklenir.

Saat dilimi kuralı verilerine ihtiyaç duyan Android sistem bileşenleri, önce aşağıdaki konumları kontrol edin:

• libcore/ ve bionic/ kodu, tzdata ve tzlookup.xml dosyalarının /data kopyasını kullanır.
• ICU4J/ICU4C kodu /data içindeki dosyaları kullanır ve mevcut olmayan veriler için (formatlar, yerelleştirilmiş dizeler vb. için) /system dosyalarına geri döner.

Dağıtım dosyaları

Distro .zip dosyaları, /data/misc/zoneinfo/current dizini doldurmak için gereken veri dosyalarını içerir. Dağıtım dosyaları ayrıca, cihazların sürüm oluşturma sorunlarını algılamasına olanak tanıyan meta veriler içerir.

ICU sürümü, Android platform gereksinimleri ve diğer sürüm değişiklikleri ile içerik değiştiğinden, dağıtım dosyası biçimi Android sürümüne bağlıdır. Android, her IANA güncellemesi için desteklenen Android sürümleri için dağıtım dosyaları sağlar (platform sistem dosyalarını güncellemeye ek olarak). OEM'ler cihazlarını güncel tutmak için bu dağıtım dosyalarını kullanabilir veya Android kaynak ağacını (dağıtım dosyaları oluşturmak için gereken komut dosyalarını ve diğer dosyaları içeren) kullanarak kendi dağıtım dosyalarını oluşturabilir.

Saat dilimi güncelleme bileşenleri

Zaman dilimi kuralları güncellemesi, dağıtım dosyalarının bir cihaza iletilmesini ve içerdiği dosyaların güvenli kurulumunu içerir. Aktarım ve kurulum aşağıdakileri gerektirir:

• Varsayılan olarak devre dışı bırakılan platform hizmeti işlevi ( timezone.RulesManagerService ). OEM'ler, yapılandırma yoluyla işlevselliği etkinleştirmelidir. RulesManagerService , sistem sunucusu işleminde çalışır ve /data/misc/zoneinfo/staged öğesine yazarak saat dilimi güncelleme işlemlerini gerçekleştirir. RulesManagerService ayrıca önceden hazırlanmış işlemleri değiştirebilir veya silebilir.
• TimeZoneUpdater , güncellenemeyen bir sistem uygulaması (diğer adıyla Updater uygulaması ). OEM'ler, bu uygulamayı, özelliği kullanan cihazların sistem görüntüsüne dahil etmelidir.
• OEM TimeZoneData , dağıtım dosyalarını cihaza taşıyan ve bunları Güncelleyici uygulamasında kullanılabilir hale getiren güncellenebilir bir sistem uygulaması (diğer adıyla Veri uygulaması ). OEM'ler, bu uygulamayı, özelliği kullanan cihazların sistem görüntüsüne dahil etmelidir.
• tzdatacheck , saat dilimi güncellemelerinin doğru ve güvenli çalışması için gereken bir önyükleme zamanı ikili dosyası.

Android kaynak ağacı, OEM'in değişiklik yapmadan kullanmayı seçebileceği yukarıdaki bileşenler için genel kaynak kodunu içerir. OEM'lerin bu özelliği doğru şekilde etkinleştirip etkinleştirmediklerini otomatik olarak kontrol etmelerini sağlamak için test kodu sağlanır.

Dağıtım kurulumu

Dağıtım yükleme işlemi aşağıdaki adımları içerir:

1. Veri uygulaması, bir uygulama mağazası indirmesi veya yandan yükleme yoluyla güncellenir . Sistem sunucusu işlemi ( timezone.RulesManagerServer/timezone.PackageTracker sınıfları aracılığıyla), yapılandırılmış, OEM'e özgü Veri uygulaması paketi adındaki değişiklikleri izler.
   
   

   

2. Sistem sunucusu işlemi, Güncelleyici Uygulamasına benzersiz, tek kullanımlık bir belirteçle hedeflenen bir amacı yayınlayarak bir güncelleme kontrolünü tetikler . Sistem sunucusu, tetiklediği en son kontrolün ne zaman tamamlandığını belirleyebilmesi için oluşturduğu en son belirteci takip eder; diğer belirteçler yoksayılır.
   
   

   

3. Güncelleme kontrolü sırasında Güncelleyici uygulaması aşağıdaki görevleri gerçekleştirir:
   • RulesManagerService'i çağırarak geçerli aygıt durumunu sorgular.
     
     

     

   • Dağıtım hakkında bilgi almak için iyi tanımlanmış bir ContentProvider URL'sini ve sütun özelliklerini sorgulayarak Veri uygulamasını sorgular.
     
     

     

4. Güncelleyici uygulaması, sahip olduğu bilgilere göre uygun eylemi gerçekleştirir . Kullanılabilir eylemler şunları içerir:
   • Kurulum talep edin. Dağıtım verileri, Veri uygulamasından okunur ve sistem sunucusundaki RulesManagerService'e iletilir. RulesManagerService, dağıtım biçimi sürümünün ve içeriğinin aygıt için uygun olduğunu yeniden onaylar ve yüklemeyi gerçekleştirir.
   • Kaldırma isteğinde bulunun (bu nadirdir). Örneğin, /data içindeki güncellenmiş APK devre dışı bırakılıyor veya kaldırılıyorsa ve cihaz /system içinde bulunan sürüme dönüyorsa.
   • Hiçbir şey yapma. Veri uygulaması dağıtımının geçersiz olduğu tespit edildiğinde gerçekleşir.
   Her durumda, Updater uygulaması, kontrol belirteciyle RulesManagerService'i çağırır, böylece sistem sunucusu, kontrolün tamamlandığını ve başarılı olduğunu bilir.
   
   

   

5. Yeniden başlat ve tzdatacheck. Aygıt yeniden başlatıldığında, tzdatacheck ikili herhangi bir aşamalı işlemi yürütür. tzdatacheck ikili dosyası aşağıdaki görevleri gerçekleştirebilir:
   • Diğer sistem bileşenleri açılmadan ve dosyaları kullanmaya başlamadan önce /data/misc/zoneinfo/current dosyalarının oluşturulmasını, değiştirilmesini ve/veya silinmesini işleyerek aşamalı işlemi gerçekleştirin.
   • /data içindeki dosyaların mevcut platform sürümü için doğru olup olmadığını kontrol edin; cihaz henüz bir sistem güncellemesi aldıysa ve dağıtım biçimi sürümü değiştiyse durum böyle olmayabilir.
   • IANA kuralları sürümünün /system içindeki sürümle aynı veya daha yeni olduğundan emin olun. Bu, /system görüntüsünde mevcut olandan daha eski saat dilimi kuralları verileriyle bir cihazdan ayrılan bir sistem güncellemesine karşı koruma sağlar.

Güvenilirlik

Uçtan uca yükleme işlemi eşzamansızdır ve üç işletim sistemi işlemine bölünür. Kurulum sırasında herhangi bir noktada, cihaz güç kaybedebilir, disk alanı tükenebilir veya kurulum kontrolünün tamamlanmamasına neden olacak başka sorunlarla karşılaşabilir. En iyi başarısız durumda, Güncelleyici uygulaması sistem sunucusuna başarısız olduğunu bildirir; En kötü başarısız durumda, RulesManagerService hiçbir çağrı almaz.

Bunu halletmek için sistem sunucusu kodu, tetiklenen bir güncelleme kontrolünün tamamlanıp tamamlanmadığını ve Data App'in en son kontrol edilen sürüm kodunun ne olduğunu takip eder. Cihaz boştayken ve şarj olurken, sistem sunucu kodu mevcut durumu kontrol edebilir. Eksik bir güncelleme denetimi veya beklenmeyen bir Veri Uygulaması sürümü tespit ederse, kendiliğinden bir güncelleme denetimini tetikler.

Güvenlik

Etkinleştirildiğinde, sistem sunucusundaki RulesManagerService kodu, sistemin kullanımının güvenli olduğundan emin olmak için birkaç kontrol gerçekleştirir.

• Kötü yapılandırılmış bir sistem görüntüsünü gösteren sorunlar, aygıtın önyüklemesini engeller; Örnekler arasında hatalı bir Güncelleyici veya Veri uygulaması yapılandırması veya Güncelleyici veya Veri uygulamasının /system/priv-app içinde olmaması yer alır.
• Kötü bir Veri uygulamasının yüklendiğini gösteren sorunlar, bir aygıtın önyüklenmesini engellemez, ancak bir güncelleme denetiminin tetiklenmesini engeller; örnekler, gerekli sistem izinlerinin olmamasını veya Data uygulamasının, beklenen URI'de bir ContentProvider göstermemesini içerir.

/data/misc/zoneinfo dizinleri için dosya izinleri SELinux kuralları kullanılarak uygulanır. Herhangi bir APK'da olduğu gibi, Veri uygulaması, /system/priv-app sürümünü imzalamak için kullanılan anahtarla imzalanmalıdır. Veri uygulamasının özel, OEM'e özgü bir paket adına ve anahtarına sahip olması bekleniyor.

Saat dilimi güncellemelerini entegre etme

OEM'ler, saat dilimi güncelleme özelliğini etkinleştirmek için genellikle:

• Kendi Veri uygulamasını oluşturun.
• Güncelleyici ve Veri uygulamalarını sistem görüntüsü derlemesine dahil edin.
• RulesManagerService'i etkinleştirmek için sistem sunucusunu yapılandırın.

hazırlanıyor

Başlamadan önce OEM'ler aşağıdaki politika, kalite güvencesi ve güvenlik hususlarını gözden geçirmelidir:

• Veri uygulamaları için uygulamaya özel özel bir imzalama anahtarı oluşturun.
• Hangi cihazların güncelleneceğini ve güncellemelerin yalnızca bunlara ihtiyaç duyan cihazlara yüklenmesini nasıl sağlayabileceklerini anlamak için saat dilimi güncellemeleri için bir sürüm ve sürüm oluşturma stratejisi oluşturun. Örneğin, OEM'ler tüm cihazları için tek bir Veri uygulamasına sahip olmak isteyebilir veya farklı cihazlar için farklı Veri uygulamalarına sahip olmayı seçebilir. Karar, paket adı seçimini, muhtemelen kullanılan sürüm kodlarını ve KG stratejisini etkiler.
• AOSP'den stok Android saat dilimi verilerini kullanmak mı yoksa kendilerininkini oluşturmak mı istediklerini anlayın.

Veri uygulaması oluşturma

AOSP, AndroidManifest.xml ve package packages/apps/TimeZoneData/oem_template içinde bulunan diğer dosyalar için talimatlar ve örnek şablonlar ile package packages/apps/TimeZoneData içinde bir Veri uygulaması oluşturmak için gereken tüm kaynak kodunu ve yapı kurallarını içerir. Örnek şablonlar, hem gerçek Veri uygulaması APK'sı için bir yapı hedefi hem de Veri uygulamasının test sürümlerini oluşturmak için ek hedefler içerir.

OEM'ler, Veri uygulamasını kendi simgeleri, adları, çevirileri ve diğer ayrıntılarıyla özelleştirebilir. Ancak Veri uygulaması başlatılamadığından simge yalnızca Ayarlar > Uygulamalar ekranında görünür.

Veri uygulamasının, sistem görüntüsüne eklenmeye (ilk sürüm için) ve bir uygulama mağazası aracılığıyla imzalanıp dağıtılmaya (sonraki güncellemeler için) uygun APK'lar üreten bir tapas yapısıyla oluşturulması amaçlanmıştır. Tapas kullanmayla ilgili ayrıntılar için bkz. Tapas kullanarak Veri uygulamasını oluşturma.

OEM'ler, /system/priv-app içindeki bir cihazın sistem görüntüsünde önceden oluşturulmuş Veri uygulamasını yüklemelidir. Önceden oluşturulmuş APK'ları (tapas oluşturma işlemi tarafından oluşturulan) sistem görüntüsüne dahil etmek için OEM'ler, örnek dosyaları packages/apps/TimeZoneData/oem_template/data_app_prebuilt . Örnek şablonlar ayrıca Data uygulamasının test sürümlerini test paketlerine dahil etmek için derleme hedefleri içerir.

Güncelleyici ve Veri uygulamalarını sistem görüntüsüne dahil etme

OEM'ler, Güncelleyici ve Veri uygulaması APK'larını sistem görüntüsünün /system/priv-app dizinine yerleştirmelidir. Bunu yapmak için sistem görüntüsü derlemesi, Updater uygulamasını ve Data uygulaması önceden oluşturulmuş hedeflerini açıkça içermelidir.

Güncelleyici uygulaması, platform anahtarıyla imzalanmalı ve diğer herhangi bir sistem uygulaması olarak dahil edilmelidir. Hedef, packages/apps/TimeZoneUpdater içinde TimeZoneUpdater olarak tanımlanır. Veri uygulamasının dahil edilmesi OEM'e özeldir ve ön derleme için seçilen hedef adına bağlıdır.

Sistem sunucusunu yapılandırma

Saat dilimi güncellemelerini etkinleştirmek için OEM'ler, frameworks/base/core/res/res/values/config.xml içinde tanımlanan yapılandırma özelliklerini geçersiz kılarak sistem sunucusunu yapılandırabilir.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Yanlış yapılandırılmış bir aygıt önyüklemeyi reddedebileceğinden, yapılandırma geçersiz kılma işlemleri sistem görüntüsünde (satıcı veya diğer değil) olmalıdır. Yapılandırma geçersiz kılmaları satıcı görüntüsündeyse, Veri uygulaması olmayan (veya farklı Veri uygulaması/Updater uygulaması paket adlarına sahip) bir sistem görüntüsüne güncelleme yapmak yanlış yapılandırma olarak kabul edilir.

xTS testi

xTS, Tradefed (CTS ve VTS gibi) kullanan standart Android test takımlarına benzeyen OEM'e özel herhangi bir test takımı anlamına gelir. Bu tür test paketlerine sahip OEM'ler, aşağıdaki konumlarda sağlanan Android saat dilimi güncelleme testlerini ekleyebilir:

• packages/apps/TimeZoneData/testing/xts , temel otomatikleştirilmiş işlevsel testler için gereken kodu içerir.
• package packages/apps/TimeZoneData/oem_template/xts xts, testleri Tradefed benzeri bir xTS paketine dahil etmek için örnek bir dizin yapısı içerir. Diğer şablon dizinlerinde olduğu gibi, OEM'lerin kendi ihtiyaçlarına göre kopyalaması ve özelleştirmesi beklenir.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt , testin gerektirdiği önceden oluşturulmuş test APK'larını dahil etmek için derleme zamanı yapılandırmasını içerir.

Saat dilimi güncellemeleri oluşturma

IANA yeni bir saat dilimi kuralı seti yayınladığında, Android çekirdek kitaplıkları ekibi AOSP'deki sürümleri güncellemek için yamalar oluşturur. Stok Android sistemini ve dağıtım dosyalarını kullanan OEM'ler bu taahhütleri alabilir, Veri uygulamalarının yeni bir sürümünü oluşturmak için kullanabilir ve ardından üretimdeki cihazlarını güncellemek için yeni sürümü yayınlayabilir.

Veri uygulamaları Android sürümlerine yakından bağlı dağıtım dosyaları içerdiğinden, OEM'lerin bir OEM'in güncellemek istediği desteklenen her Android sürümü için Veri uygulamasının yeni bir sürümünü oluşturması gerekir. Örneğin, bir OEM Android 8.1, 9 ve 10 cihazlar için güncellemeler sağlamak isterse işlemi üç kez tamamlamalıdır.

1. Adım: Sistem/zaman dilimi ve harici/icu veri dosyalarının güncellenmesi

Bu adımda, OEM'ler AOSP'deki sürüm -dev dallarından system/timezone ve external/icu icu için stok Android taahhütlerini alır ve bu taahhütleri kendi Android kaynak kodu kopyalarına uygular.

system/timezone AOSP yaması system/timezone/input_data ve system/timezone/output_data içindeki güncellenmiş dosyaları içerir. Ek yerel düzeltmeler yapması gereken OEM'ler giriş dosyalarını değiştirebilir ve ardından system/timezone/input_data ve external/icu icu içindeki dosyaları output_data içinde dosya oluşturmak için kullanabilir.

En önemli dosya, Data uygulaması APK oluşturulduğunda otomatik olarak dahil edilen system/timezone/output_data/distro/distro.zip .

2. Adım: Veri uygulamasının sürüm kodunu güncelleme

Bu adımda OEM'ler, Veri uygulamasının sürüm kodunu günceller. Derleme otomatik olarak distro.zip alır, ancak Veri uygulamasının yeni sürümünün yeni olarak tanınması ve önceden yüklenmiş bir Veri uygulamasını veya bir cihaza yüklenmiş bir Veri uygulamasını önceki bir güncellemeyle değiştirmek için kullanılması için yeni bir sürüm koduna sahip olması gerekir.

package/apps/TimeZoneData/oem_template/data_app kopyalanan dosyaları kullanarak Data uygulamasını oluştururken, APK'ya uygulanan sürüm kodunu/sürüm adını Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Benzer girişler testing/Android.mk içinde bulunabilir (ancak test sürümü kodları sistem görüntüsü sürümünden daha yüksek olmalıdır). Ayrıntılar için, örnek sürüm kodu strateji şemasına bakın; örnek şema veya benzer bir şema kullanılıyorsa, gerçek sürüm kodlarından daha yüksek olmaları garanti edildiğinden test sürüm kodlarının güncellenmesi gerekmez.

3. Adım: Yeniden oluşturma, imzalama, test etme ve yayınlama

Bu adımda, OEM'ler tapas kullanarak APK'yı yeniden oluşturur, oluşturulan APK'yi imzalar ve ardından APK'yı test edip yayınlar:

• Yayınlanmamış cihazlar için (veya piyasaya sürülen bir cihaz için sistem güncellemesi hazırlarken), sistem görüntüsünün ve xTS testlerinin en son APK'lara sahip olduğundan emin olmak için yeni APK'ları Veri uygulaması önceden oluşturulmuş dizinine gönderin. OEM'ler, yeni dosyanın doğru çalışıp çalışmadığını test etmelidir (yani, CTS'yi ve OEM'e özgü tüm otomatik ve manuel testleri geçer).
• Artık sistem güncellemelerini almayan piyasaya sürülen cihazlar için imzalanan APK yalnızca bir uygulama mağazası aracılığıyla yayınlanabilir.

OEM'ler, kalite güvencesinden ve güncellenmiş Veri uygulamasını piyasaya çıkmadan önce cihazlarında test etmekten sorumludur.

Veri uygulaması sürüm kodu stratejisi

Cihazların doğru APK'ları almasını sağlamak için Veri uygulamasının uygun bir sürüm oluşturma stratejisi olması gerekir. Örneğin, uygulama mağazasından indirilenden daha eski bir APK içeren bir sistem güncellemesi alınırsa, uygulama mağazası sürümü korunmalıdır.

APK sürüm kodu aşağıdaki bilgileri içermelidir:

• Dağıtım biçimi sürümü (majör + minör)
• Artan (opak) bir sürüm numarası

Şu anda platform API düzeyi, dağıtım biçimi sürümüyle güçlü bir şekilde ilişkilidir, çünkü her API düzeyi genellikle yeni bir YBÜ sürümüyle ilişkilendirilir (bu, dağıtım dosyalarını uyumsuz hale getirir). Gelecekte, Android bunu bir dağıtım dosyasının birden çok Android platformu sürümünde çalışabilmesi için değiştirebilir (ve Veri uygulaması sürüm kod şemasında API düzeyi kullanılmaz).

Örnek sürüm kodu stratejisi

Bu örnek sürüm oluşturma numarası şeması, daha yüksek dağıtım biçimi sürümlerinin daha düşük dağıtım biçimi sürümlerinin yerini almasını sağlar. AndroidManifest.xml , eski cihazların kaldırabileceklerinden daha yüksek dağıtım biçimi sürümüne sahip sürümleri almamasını sağlamak için android:minSdkVersion kullanır.

Ondalık sayı yerine ikili sayı kullanılsaydı şema daha iyi paketlenebilirdi, ancak bu şema insan tarafından okunabilir olma avantajına sahiptir. Tam sayı aralığı tükenirse Veri uygulaması paketi adı değişebilir.

Sürüm adı, ayrıntıların insan tarafından okunabilir bir temsilidir, örneğin: major=001,minor=001,iana=2017a, revision=1,respin=2 . Örnekler aşağıdaki tabloda gösterilmiştir.

• Örnek 1 ve 2, aynı 2017a IANA sürümü için farklı ana biçim sürümlerine sahip iki APK sürümünü göstermektedir. 2, sayısal olarak 1'den yüksektir; bu, daha yeni cihazların daha yüksek formatlı sürümleri almasını sağlamak için gereklidir. minSdkVersion, P sürümünün O cihazlarına sağlanmamasını sağlar.
• Örnek 3, 1 için bir revizyon/düzeltmedir ve sayısal olarak 1'den büyüktür.
• Örnek 4 ve 5, O-MR1 ve P için 2017b sürümlerini göstermektedir. Sayısal olarak daha yüksek olduklarından, ilgili öncüllerinin önceki IANA sürümlerinin/Android revizyonlarının yerini alırlar.
• Örnek 6 ve 7, O-MR1 ve P için 2018a sürümlerini göstermektedir.
• Örnek 8, Y=0 şemasını tamamen değiştirmek için Y'nin kullanımını gösterir.
• Örnek 9, apk'yi yeniden döndürmek için 3 ile 4 arasında kalan boşluğun kullanımını gösterir.

Her cihaz, sistem görüntüsünde varsayılan, uygun şekilde sürümlendirilmiş bir APK ile birlikte gönderildiğinden, bir P sistem görüntüsü sürümünden daha düşük bir sürüm numarasına sahip olduğundan, bir P cihazına O-MR1 sürümünün yüklenmesi riski yoktur. O-MR1 sürümü /data içinde kurulu olan ve daha sonra P için bir sistem güncellemesi alan bir cihaz / /data içindeki O-MR1 sürümüne tercihli olarak /system sürümünü kullanır çünkü P sürümü her zaman O- için tasarlanan herhangi bir uygulamadan daha yüksektir. MR1.

Tapas kullanarak Veri uygulamasını oluşturma

OEM'ler, saat dilimi Data uygulamasının çoğu yönünü yönetmekten ve sistem görüntüsünü doğru şekilde yapılandırmaktan sorumludur. Veri uygulamasının, sistem görüntüsüne eklenmeye (ilk sürüm için) ve bir uygulama mağazası aracılığıyla imzalanıp dağıtılmaya (sonraki güncellemeler için) uygun APK'lar üreten bir tapas yapısıyla oluşturulması amaçlanmıştır.

Tapas , uygulamaların dağıtılabilir sürümlerini üretmek için azaltılmış bir kaynak ağacı kullanan Android yapı sisteminin inceltilmiş bir sürümüdür. Normal Android derleme sistemine aşina olan OEM'ler, normal Android platform derlemesindeki derleme dosyalarını tanımalıdır.

Manifest oluşturma

Azaltılmış bir kaynak ağacı, genellikle yalnızca derleme sistemi ve uygulamayı oluşturmak için ihtiyaç duyulan Git projelerine atıfta bulunan özel bir bildirim dosyasıyla elde edilir. Bir Veri uygulaması oluşturma bölümündeki talimatları uyguladıktan sonra, OEM'ler, packages/apps/TimeZoneData/oem_template altındaki şablon dosyaları kullanılarak oluşturulmuş en az iki OEM'e özgü Git projesine sahip olmalıdır:

• Bir Git projesi, uygulama APK dosyasını oluşturmak için gereken bildirim ve derleme dosyaları gibi uygulama dosyalarını içerir (örneğin, vendor/ oem /apps/TimeZoneData ). Bu proje ayrıca, xTS testleri tarafından kullanılabilecek test APK'ları için derleme kuralları içerir.
• Bir Git projesi, sistem görüntüsü derlemesine ve xTS testlerine dahil edilmek üzere uygulama derlemesi tarafından üretilen imzalı APK'ları içerir.

Uygulama derlemesi, platform derlemesiyle paylaşılan veya OEM'den bağımsız kod kitaplıkları içeren diğer birkaç Git projesinden yararlanır.

Aşağıdaki bildirim snippet'i, saat dilimi Data uygulamasının O-MR1 derlemesini desteklemek için gereken minimum Git projeleri grubunu içerir. OEM'ler, OEM'e özgü Git projelerini (genellikle imzalama sertifikasını içeren bir projeyi içerir) bu bildirime eklemelidir ve buna göre farklı dallar yapılandırabilir.

   <!-- Tapas Build -->
    <project
        path="build"
        name="platform/build">
        <copyfile src="core/root.mk" dest="Makefile" />
    </project>
    <project
        path="prebuilts/build-tools"
        name="platform/prebuilts/build-tools"
        clone-depth="1" />
    <project
        path="prebuilts/go/linux-x86"
        name="platform/prebuilts/go/linux-x86"
        clone-depth="1" />
    <project
        path="build/blueprint"
        name="platform/build/blueprint" />
    <project
        path="build/kati"
        name="platform/build/kati" />
    <project
        path="build/soong"
        name="platform/build/soong">
        <linkfile src="root.bp" dest="Android.bp" />
        <linkfile src="bootstrap.bash" dest="bootstrap.bash" />
    </project>

    <!-- SDK for system / public API stubs -->
    <project
        path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth="1" />
    <!-- App source -->
    <project
        path="system/timezone"
        name="platform/system/timezone" />
    <project
        path="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZoneData" />
    <!-- Enable repohooks -->
    <project
        path="tools/repohooks"
        name="platform/tools/repohooks"
        revision="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Tapas yapısını çalıştırma

Kaynak ağaç oluşturulduktan sonra, aşağıdaki komutları kullanarak tapas derlemesini çağırın:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

Başarılı bir derleme, test için out/dist dizininde dosyalar oluşturur. Bu dosyalar, sistem görüntüsüne dahil edilmek üzere önceden oluşturulmuş dizine yerleştirilebilir ve/veya uyumlu cihazlar için bir uygulama mağazası aracılığıyla dağıtılabilir.