Google 致力于为黑人社区推动种族平等。查看具体举措
此页面由 Cloud Translation API 翻译。
Switch to English

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 APEX tabanlı modül güncelleme mekanizmasıyla değiştirir . AOSP, OEM'lerin APK tabanlı güncellemeleri etkinleştirmesi için gerekli platform kodunu eklemeye devam ediyor, 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. Bununla birlikte, APK tabanlı bir güncelleme APEX tabanlı bir güncellemenin yerini aldığından (yani, bir APK güncellemesi alan bir cihaz APEX tabanlı güncellemeleri yoksayacağından, APK güncelleme mekanizması modül güncellemelerini de alan bir üretim cihazında 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 gün ışığından yararlanma saatini (DST) ve saat dilimlerini güncelleyerek dini, politik ve jeopolitik nedenlerle sıkça değişebilen verileri standartlaştırır.

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

  1. IANA , Saat Dilimi Veritabanına yönelik bir güncelleme yayınlar, ülkelerindeki bir veya daha fazla hükümetin saat dilimi kuralını değiştirmesine yanıt olarak bir güncelleme yayınlar.
  2. Google veya Android iş ortağı, güncellenmiş saat dilimlerini içeren bir Saat Dilimi Verileri 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 gelen yeni saat dilimi verilerini içerir.

Modüller hakkında ayrıntılar için bkz. Modüler Sistem Bileşenleri .

Saat dilimi güncellemeleri (Android 8.1–9)

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 almasını sağlar (böylece bir Android cihazın kullanım ömrünü uzatır) ve Android iş ortaklarının saat dilimi güncellemelerini sistem görüntüsü güncellemelerinden bağımsız olarak test etmesini 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 ederse kendi veri dosyalarını oluşturabilir. Her durumda OEM'ler, destekledikleri cihazlar için kalite güvencesi / testi, zamanlama ve saat dilimi kuralı güncellemelerinin başlatılması üzerindeki kontrolü elinde tutar.

Android saat dilimi kaynak kodu ve verileri

Bu özelliği kullanmayanlar da dahil olmak üzere tüm stok Android cihazları, saat dilimi kural verilerine ihtiyaç duyar ve /system bölümündeki varsayılan saat dilimi kuralları verileriyle birlikte gönderilmelidir. Bu veriler daha sonra Android kaynak ağacındaki aşağıdaki kitaplıklarda bulunan 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/ yerel kitaplık kodu (örneğin, mktime , yerel zaman sistem çağrıları) tzdata dosyasını kullanır.
  • İçinde ICU4J / icu4c kütüphane kodu external/icu/ icu kullanır .dat dosyası.

Bu kütüphaneler /data/misc/zoneinfo/current dizininde bulunabilecek kaplama dosyalarının kaydını tutar. Bindirme dosyalarının, iyileştirilmiş saat dilimi kuralları verileri içermesi, dolayısıyla cihazların /system değişikliği olmaksızın güncellenmesine olanak sağlaması beklenir.

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

  • libcore/ ve bionic/ code, 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. İçin) /system dosyalarına geri döner.

Distro dosyaları

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

Dağıtım dosya biçimi Android sürümüne bağlıdır çünkü içerikler ICU sürümü, Android platform gereksinimleri ve diğer sürüm değişiklikleriyle değişir. 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üncellemenin yanı sıra). Cihazlarını güncel tutmak için OEM'ler bu dağıtım dosyalarını kullanabilir veya Android kaynak ağacını (dağıtım dosyalarını oluşturmak için gereken komut dosyalarını ve diğer dosyaları içeren) kullanarak kendi dosyalarını oluşturabilir.

Saat dilimi güncelleme bileşenleri

Bir saat dilimi kuralları güncellemesi, dağıtım dosyalarının bir cihaza aktarılmasını ve içerdiği dosyaların güvenli bir şekilde kurulmasını içerir. Aktarım ve kurulum aşağıdakileri gerektirir:

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

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 özelliği doğru şekilde etkinleştirip etkinleştirmediklerini otomatik olarak kontrol etmelerini sağlamak için test kodu sağlanır.

Distro kurulumu

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

  1. Veri uygulaması, bir uygulama mağazası indirme veya yan 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ü, Data uygulama paketi adındaki değişiklikleri izler.

    Veri uygulaması güncellemeleri
    Şekil 1. Veri uygulaması güncellemeleri
  2. Sistem sunucusu işlemi , Updater Uygulamasına benzersiz, tek kullanımlık bir belirteçle hedeflenen bir amaç yayınlayarak bir güncelleme kontrolünü tetikler . Sistem sunucusu, oluşturduğu en son belirteci takip eder, böylece tetiklediği en son kontrolün ne zaman tamamlandığını belirleyebilir; diğer tüm belirteçler dikkate alınmaz.

    Tetikleyici güncelleme
    Şekil 2. Tetikleyici güncelleme kontrolü
  3. Güncelleme kontrolü sırasında Updater uygulaması aşağıdaki görevleri gerçekleştirir:
    • RulesManagerService'i çağırarak mevcut cihaz durumunu sorgular.

      RulesManagerService'i çağır
      Şekil 3. Veri uygulaması güncellemeleri, RulesManagerService'i çağırma
    • 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.

      Dağıtım bilgilerini alın
      Şekil 4. Veri uygulaması güncellemeleri, dağıtım hakkında bilgi alın
  4. Updater uygulaması, sahip olduğu bilgilere göre uygun eylemi gerçekleştirir . Mevcut eylemler şunları içerir:
    • Kurulum talep edin. Distro verileri Data uygulamasından okunur ve sistem sunucusundaki RulesManagerService'e iletilir. RulesManagerService, dağıtım biçimi sürümünün ve içeriğinin cihaz için uygun olduğunu yeniden onaylar ve kurulumu aşamalar.
    • Kaldırma isteğinde bulunun (bu nadirdir). Örneğin, /data içindeki güncellenmiş APK devre dışı bırakılıyorsa veya kaldırılıyorsa ve cihaz /system içindeki mevcut sürüme dönüyorsa.
    • Hiçbir şey yapma. Data uygulama 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.

    Kontrol tamamlandı
    Şekil 5. Kontrol tamamlandı
  5. Yeniden başlatın ve tzdatacheck. Cihaz bir sonraki önyüklendiğinde, tzdatacheck ikili dosyası 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 dosyaları açmadan ve kullanmaya başlamadan önce /data/misc/zoneinfo/current dosyalarının oluşturulması, değiştirilmesi ve / veya silinmesini /data/misc/zoneinfo/current aşamalı işlemi yürütün.
    • /data içindeki dosyaların mevcut platform sürümü için doğru olup olmadığını kontrol edin; bu, cihaz yeni bir sistem güncellemesi almışsa ve dağıtım biçimi sürümü değişmişse durum bu 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 bulunandan daha eski saat dilimi kural verilerine sahip bir cihaz bırakan bir sistem güncellemesine karşı koruma /system .

Güvenilirlik

Uçtan uca kurulum süreci eşzamansızdır ve üç işletim sistemi sürecine bölünmüştür. Kurulum sırasında herhangi bir noktada aygıt güç kaybedebilir, disk alanı tükenebilir veya başka sorunlarla karşılaşarak kurulum kontrolünün tamamlanmamasına neden olabilir. En iyi başarısız durumda, Updater uygulaması sistem sunucusuna başarısız olduğunu bildirir; en kötü başarısız durumda, RulesManagerService hiç çağrı almaz.

Bunu idare etmek için, sistem sunucusu kodu, tetiklenen bir güncelleme kontrolünün tamamlanıp tamamlanmadığını ve Data App'ın en son kontrol edilen sürüm kodunun ne olduğunu izler. Cihaz boştayken ve şarj olurken, sistem sunucu kodu mevcut durumu kontrol edebilir. Eksik bir güncelleme kontrolü veya beklenmedik bir Data App sürümü keşfederse, kendiliğinden bir güncelleme kontrolünü tetikler.

Güvenlik

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

  • Kötü yapılandırılmış bir sistem görüntüsünü gösteren sorunlar, bir aygıtın önyüklemesini engeller; Örnekler arasında kötü 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.
  • Hatalı bir Data uygulamasının yüklendiğini gösteren sorunlar, bir cihazın başlatılmasını engellemez ancak bir güncelleme kontrolünün tetiklenmesini engeller; Örnekler arasında gerekli sistem izinlerinin olmaması veya Data uygulaması beklenen URI'da bir ContentProvider'ı göstermez.

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

Saat dilimi güncellemelerini entegre etme

Saat dilimi güncelleme özelliğini etkinleştirmek için OEM'ler tipik olarak:

  • Kendi Veri uygulamalarını oluşturun.
  • Updater ve Data uygulamalarını sistem görüntüsü yapısına 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 politikayı, kalite güvencesini ve güvenlik hususlarını gözden geçirmelidir:

  • Data uygulamaları için uygulamaya özel özel bir imzalama anahtarı oluşturun.
  • Hangi cihazların güncelleneceğini ve güncellemelerin yalnızca onlara ihtiyaç duyan cihazlara yüklenmesini nasıl sağlayabileceklerini anlamak için saat dilimi güncellemeleri için bir yayın 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 QA stratejisini etkiler.
  • AOSP'den stok Android saat dilimi verilerini kullanmak mı yoksa kendi saat dilimini mi oluşturmak istediklerini anlayın.

Veri uygulaması oluşturma

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

OEM'ler Veri uygulamasını kendi simgeleri, adları, çevirileri ve diğer ayrıntılarla ö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) uygun APK'lar üreten ve bir uygulama mağazası aracılığıyla imzalanıp dağıtıldığı (sonraki güncellemeler için) bir tapas yapısı ile oluşturulması amaçlanmıştır. Tapas kullanmayla ilgili ayrıntılar için, Tapas kullanarak Veri uygulamasını oluşturma bölümüne bakın.

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

Updater ve Data uygulamalarını sistem görüntüsüne dahil etme

OEM'ler, Updater ve Data uygulama 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, Güncelleyici uygulamasını ve önceden oluşturulmuş Veri uygulaması hedeflerini açıkça içermelidir.

Updater uygulaması, platform anahtarıyla imzalanmalı ve diğer herhangi bir sistem uygulaması olarak dahil edilmelidir. Hedef tanımlanan packages/apps/TimeZoneUpdater olarak TimeZoneUpdater . Veri uygulamasının dahil edilmesi OEM'e özgüdür ve ön oluşturma 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 tanımlanan yapılandırma özelliklerini geçersiz kılarak sistem sunucusunu yapılandırabilir.

Emlak Açıklama Geçersiz Kılma Gerekli mi?
config_enableUpdateableTimeZoneRules
RulesManagerService'i etkinleştirmek için true olarak ayarlanmalıdır. Evet
config_timeZoneRulesUpdateTrackingEnabled
Sistemin Data uygulamasındaki değişiklikleri dinlemesi için true olarak ayarlanmalıdır. Evet
config_timeZoneRulesDataPackage
OEM'e özgü Veri uygulamasının paket adı. Evet
config_timeZoneRulesUpdaterPackage
Varsayılan Updater uygulaması için yapılandırılmıştır. Yalnızca farklı bir Güncelleyici uygulaması uygulaması sağlarken değiştirin. Hayır
config_timeZoneRulesCheckTimeMillisAllowed
RulesManagerService tarafından tetiklenen bir güncelleme kontrolü ile yükleme, kaldırma veya hiçbir şey yapma yanıtı arasında izin verilen süre. Bu noktadan sonra, kendiliğinden bir güvenilirlik tetikleyicisi oluşturulabilir. Hayır
config_timeZoneRulesCheckRetryCount
RulesManagerService daha fazlasını oluşturmayı durdurmadan önce izin verilen sıralı başarısız güncelleme kontrollerinin sayısı. Hayır

Yanlış yapılandırılmış bir aygıt önyüklemeyi reddedebileceğinden, yapılandırma geçersiz kılmaları sistem görüntüsünde (satıcı veya başka bir yerde değil) olmalıdır. Yapılandırma geçersiz kılmaları satıcı görüntüsünde olsaydı, bir Veri uygulaması olmadan (veya farklı Veri uygulaması / Güncelleyici uygulama paketi adlarıyla) bir sistem görüntüsüne güncelleme yapılması, yanlış yapılandırma olarak kabul edilir.

xTS testi

xTS, Tradefed (CTS ve VTS gibi) kullanan standart Android test paketlerine benzeyen herhangi bir OEM'e özgü test paketini ifade eder. 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 test için gereken kodu içerir.
  • package packages/apps/TimeZoneData/oem_template/xts xts, Tradefed benzeri bir xTS paketindeki testleri 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, bunları Data 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ümleriyle yakından bağlantı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üncelleme sağlamak isterse, işlemi üç kez tamamlaması gerekir.

Adım 1: Sistem / saat dilimi ve harici / icu veri dosyalarını güncelleme

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 Android kaynak kodunun kopyalarına uygular.

Sistem / saat dilimi AOSP yaması, system/timezone/input_data system/timezone/output_data ve system/timezone/output_data güncellenmiş dosyaları içerir. Ek yerel düzeltmeler yapması gereken OEM'ler giriş dosyalarını değiştirebilir ve daha sonra output_data dosyalar oluşturmak için system/timezone/input_data ve external/icu output_data dosyaları output_data .

En önemli dosya system/timezone/output_data/distro/distro.zip ve Data app APK oluşturulduğunda otomatik olarak eklenir.

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

Bu adımda OEM'ler Data uygulamasının sürüm kodunu günceller. distro.zip , distro.zip otomatik olarak alır, ancak Veri uygulamasının yeni sürümünün yeni bir sürüm koduna sahip olması gerekir, böylece yeni olarak distro.zip 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ılır.

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

testing/Android.mk da benzer girişler 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ırsa, test sürüm kodlarının güncellenmesine gerek yoktur çünkü gerçek sürüm kodlarından daha yüksek olmaları garanti edilir.

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

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

  • Yayınlanmamış cihazlar için (veya yayınlanmış bir cihaz için bir 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ı Data uygulaması önceden oluşturulmuş dizinine gönderin. OEM'ler yeni dosyanın düzgün çalışıp çalışmadığını test etmelidir (yani, CTS'yi ve OEM'e özgü otomatik ve manuel testleri geçer).
  • Artık sistem güncellemelerini almayan yayınlanmış cihazlar için imzalı APK yalnızca bir uygulama mağazası aracılığıyla yayınlanabilir.

OEM'ler, kalite güvencesi ve güncellenmiş Data uygulamasının piyasaya sürülmeden önce cihazlarında test edilmesinden sorumludur.

Veri uygulaması sürüm kodu stratejisi

Veri uygulamasının, cihazların doğru APK'ları almasını sağlamak için uygun bir sürüm oluşturma stratejisine sahip 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:

  • Distro format sürümü (büyük + küçük)
  • Artan (opak) bir sürüm numarası

Şu anda, platform API seviyesi dağıtım formatı sürümüyle güçlü bir şekilde ilişkilidir, çünkü her API seviyesi genellikle yeni bir ICU sürümü ile ilişkilendirilir (bu da dağıtım dosyalarını uyumsuz hale getirir). Gelecekte, Android, bir dağıtım dosyasının birden çok Android platformu sürümünde çalışabilmesi için bunu değiştirebilir (ve API düzeyi, Data uygulaması sürüm kod şemasında 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 başa çıkabileceklerinden daha yüksek bir dağıtım biçimi sürümüne sahip sürümleri android:minSdkVersion sağlamak için android:minSdkVersion kullanır.

Sürüm kontrolü
Şekil 6. Örnek sürüm kodu stratejisi
Misal Değer Amaç
Y Ayrılmış Gelecekteki alternatif şemalara / test APK'larına izin verir. Başlangıçta (örtük olarak) 0. Temel alınan tür imzalı bir 32 bit int türü olduğundan, bu şema en fazla iki gelecek numaralandırma şeması revizyonunu destekler.
01 Ana biçim sürümü 3 ondalık basamaklı ana biçim sürümünü izler. Dağıtım biçimi 3 ondalık basamağı destekler, ancak burada yalnızca 2 basamak kullanılır. API seviyesi başına beklenen büyük artış göz önüne alındığında 100'e ulaşma olasılığı düşüktür. Ana sürüm 1, API seviyesi 27'ye eşdeğerdir.
1 Küçük format versiyonu 3 ondalık basamaklı küçük biçim sürümünü izler. Dağıtım biçimi 3 ondalık basamağı destekler, ancak burada yalnızca 1 basamak kullanılır. 10'a ulaşması pek olası değil.
X Ayrılmış Üretim sürümleri için 0'dır (ve test APK'ları için farklı olabilir).
ZZZZZ Opak sürüm numarası Talep üzerine tahsis edilen ondalık sayı. Gerekirse geçiş reklamı güncellemelerinin yapılmasına izin veren boşluklar içerir.

Şema, ondalık yerine ikili kullanılırsa daha iyi paketlenebilir, ancak bu şema, insan tarafından okunabilir olma avantajına sahiptir. Tam sayı aralığı tükendiyse, Data uygulaması paket 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österilmektedir.

# Sürüm kodu minSdkVersion {Ana biçim sürümü}, {İkincil biçim sürümü}, {IANA kuralları sürümü}, {Revizyon}
1 11000010 O-MR1 majör = 001, minör = 001, iana = 2017a, revizyon = 1
2 21000010 P majör = 002, minör = 001, iana = 2017a, revizyon = 1
3 11000020 O-MR1 majör = 001, minör = 001, iana = 2017a, revizyon = 2
4 11000030 O-MR1 majör = 001, minör = 001, iana = 2017b, revizyon = 1
5 21000020 P majör = 002, minör = 001, iana = 2017b, revizyon = 1
6 11000040 O-MR1 majör = 001, minör = 001, iana = 2018a, revizyon = 1
7 21000030 P majör = 002, minör = 001, iana = 2018a, revizyon = 1
8 1123456789 - -
9 11000021 O-MR1 majör = 001, minör = 001, iana = 2017a, revizyon = 2, respin = 2
  • Örnek 1 ve 2, farklı ana biçim sürümlerine sahip aynı 2017a IANA sürümü için iki APK sürümünü gösterir. 2, sayısal olarak 1'den büyüktür; bu, daha yeni cihazların daha yüksek format sürümlerini almasını sağlamak için gereklidir. MinSdkVersion, P sürümünün O cihazlara sağlanmamasını sağlar.
  • Örnek 3, 1 için bir revizyon / düzeltmedir ve sayısal olarak 1'den büyüktür.
  • Örnekler 4 ve 5, O-MR1 ve P için 2017b sürümlerini gösterir. Sayısal olarak daha yüksek olan bu sürümler, ilgili öncüllerinin önceki IANA sürümlerinin / Android revizyonlarının yerini alır.
  • Örnek 6 ve 7, O-MR1 ve P için 2018a sürümlerini gösterir.
  • Örnek 8, Y = 0 şemasını tamamen değiştirmek için Y'nin kullanımını göstermektedir.
  • Örnek 9, apk'yi yeniden döndürmek için 3 ile 4 arasında kalan boşluğun kullanımını göstermektedir.

Her cihaz, sistem görüntüsünde varsayılan, uygun şekilde sürümlendirilmiş bir APK ile birlikte gönderildiği için, 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 bir O-MR1 sürümünün yüklenmesi riski yoktur. Yüklü bir O-MR1 versiyonu olan bir cihaz /data daha sonra P, bir sistem güncelleştirme alır kullanır /system O-MR1 sürümüne tercihen sürüm /data P versiyonu her zaman daha yüksek bir uygulama O- yönelik daha uzun olduğundan MR1.

Tapas kullanarak Data uygulamasını oluşturma

OEM'ler, saat dilimi Veri 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) uygun APK'lar üreten ve bir uygulama mağazası aracılığıyla imzalanıp dağıtıldığı (sonraki güncellemeler için) bir tapas yapısı ile 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 derleme sisteminin zayıflatılmış bir sürümüdür. Normal Android derleme sistemine aşina OEM'ler, derleme dosyalarını normal Android platform yapısından tanımalıdır.

Manifest yaratmak

Küçültülmüş bir kaynak ağacı genellikle yalnızca derleme sistemi tarafından ihtiyaç duyulan Git projelerine ve uygulamayı oluşturmak için başvuran özel bir bildirim dosyasıyla elde edilir. Bir Veri uygulaması Oluşturma'daki talimatları izledikten 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, manifest ve uygulama APK dosyasını oluşturmak için gereken 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 parçacığı, saat dilimi Data uygulamasının bir O-MR1 derlemesini desteklemek için gereken minimum Git projesi kümesini 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ğacı oluşturulduktan sonra, aşağıdaki komutları kullanarak tapas yapısını ç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 üretir. Bu dosyalar, sistem görüntüsüne dahil edilmek üzere prebuilts dizinine yerleştirilebilir ve / veya uyumlu cihazlar için bir uygulama mağazası aracılığıyla dağıtılabilir.