Standart başlatma nedeni

Android 9, bootloader başlatma nedeni spesifikasyonunda aşağıdaki değişiklikleri içerir.

Başlatma nedenleri

Önyükleyici, bir cihazın neden yeniden başlatıldığını belirlemek için benzersiz donanım ve bellek kaynaklarını kullanır. Ardından, Android çekirdek komut satırına androidboot.bootreason=<reason> ekleyerek bu belirlemeyi iletir. init daha sonra bu komut satırını, Android mülkü bootloader_boot_reason_prop'a (ro.boot.bootreason) dağıtılacak şekilde çevirir. Android 12 veya sonraki sürümlerle kullanıma sunulan ve 5.10 veya daha yeni bir çekirdek sürümü kullanan cihazlarda, çekirdek komut satırı yerine androidboot.bootreason=<reason>, bootconfig'e eklenir.

Başlatma nedeni özellikleri

Android'in önceki sürümlerinde, boşluk kullanılmayan, tamamen küçük harflerden oluşan, birkaç şart içeren (ör. kernel_panic, watchdog, cold/warm/hard bildirme) ve diğer benzersiz nedenler için izin verilen bir önyükleme nedeni biçimi belirtiliyordu. Bu gevşek spesifikasyon, yüzlerce özel (ve bazen anlamsız) önyükleme nedeni dizesinin çoğalmasına neden oldu ve bu da yönetilemez bir duruma yol açtı. Mevcut Android sürümünden itibaren, bootloader tarafından gönderilen neredeyse ayrıştırılamaz veya anlamsız içeriklerin ivmesi bootloader_boot_reason_prop için uyumluluk sorunları oluşturdu.

Android 9 sürümüyle birlikte Android ekibi, eski bootloader_boot_reason_prop'ün önemli bir ivme kazandığını ve çalışma zamanında yeniden yazılamayacağını fark etti. Bu nedenle, başlatma nedeni spesifikasyonundaki tüm iyileştirmeler, bootloader geliştiricileriyle etkileşimlerden ve mevcut sistemde yapılan düzenlemelerden gelmelidir. Bu doğrultuda Android Ekibi:

  • Aşağıdakileri yapmaya teşvik etmek için önyükleme programı geliştiricileriyle etkileşim kurma:
    • bootloader_boot_reason_prop öğesine standart, ayrıştırılabilir ve tanınabilir nedenler sağlayın.
    • system/core/bootstat/bootstat.cpp kBootReasonMap listesine katılın.
  • system_boot_reason_prop (sys.boot.reason) için kontrollü ve çalışma zamanında yeniden yazılabilir bir kaynak ekleme. Bu mülkü, sınırlı sayıda sistem uygulaması (bootstat ve init gibi) yeniden yazabilir ancak tüm uygulamalara bu mülkü okumak için sepolicy hakları verilebilir.
  • Kullanıcıları, sistem önyükleme nedeni mülkünde bulunan içeriğe güvenmeden önce userdata'nın monte edilmesini beklemeleri konusunda bilgilendirme system_boot_reason_prop.

Neden bu kadar geç? bootloader_boot_reason_prop, önyükleme işleminin başlarında kullanılabilir ancak yanlış, ayrıştırılamaz ve standart olmayan bilgiler içerdiği için Android güvenlik politikası tarafından gerektiğinde engellenir. Çoğu durumda, yalnızca başlatma sistemi hakkında derinlemesine bilgi sahibi olan geliştiricilerin bu bilgilere erişmesi gerekir. system_boot_reason_prop ile başlatma nedeni için rafine, ayrıştırılabilir ve standart bir API, yalnızca userdata yüklendikten sonra güvenilir ve doğru bir şekilde alınabilir. Özellikle:

  • Kullanıcı verileri eklenmeden önce system_boot_reason_prop, bootloader_boot_reason_prop değerini içerir.
  • userdata yüklendikten sonra system_boot_reason_prop, uyumlu olacak veya daha doğru bilgi bildirecek şekilde güncellenebilir.

Bu nedenle Android 9, önyükleme nedeninin resmi olarak alınabilmesi için geçen süreyi uzatır. Böylece, önyüklemede hemen doğru olan (bootloader_boot_reason_prop ile) bu bilgi, yalnızca userdata bağlandıktan sonra (system_boot_reason_prop ile) kullanılabilir hale gelir.

Bootstat mantığı, daha bilgilendirici ve uyumlu bir bootloader_boot_reason_prop kullanılmasını gerektirir. Bu mülk, öngörülebilir bir biçim kullandığında tüm kontrollü yeniden başlatma ve kapatma senaryolarının doğruluğu artar. Bu da system_boot_reason_prop değerinin doğruluğunu ve anlamını hassaslaştırır ve genişletir.

Standart önyükleme nedeni biçimi

Android 9'daki bootloader_boot_reason_prop için standart önyükleme nedeni biçiminde şu söz dizimi kullanılır: 

<reason>,<subreason>,<detail>…

Biçimlendirme kuralları:

  • Küçük harf
  • Boşluk yok (altı çizili kullanın)
  • Tüm basılabilir karakterler
  • Virgülle ayrılmış reason, subreason ve bir veya daha fazla detail örneği.
    • Cihazın yeniden başlatılması veya kapatılmasının en yüksek öncelikli nedenini temsil eden gerekli reason.
    • Cihazın neden yeniden başlatılmasının veya kapatılmasının (ya da kimin yeniden başlatılmasının veya kapatılmasının) kısa bir özetini temsil eden isteğe bağlı bir subreason.
    • Bir veya daha fazla isteğe bağlı detail değeri. detail, subreason'ye yol açan belirli sistemin belirlenmesine yardımcı olmak için bir alt sistemi işaret edebilir. Birden fazla detail değeri belirtebilirsiniz. Bunlar genellikle bir önem hiyerarşisini izlemelidir. Ancak eşit öneme sahip birden fazla detail değerinin raporlanması da kabul edilir.

bootloader_boot_reason_prop için boş bir değer, diğer aracıların daha sonra bir önyükleme nedeni eklemesine izin verdiğinden yasa dışı kabul edilir.

Neden şartları

reason için verilen değer (bitiş veya virgülden önceki ilk span), çekirdek, güçlü ve keskin nedenlere ayrılmış aşağıdaki gruptan olmalıdır:

  • çekirdek grubu:
    • "watchdog"
    • "kernel_panic"
  • güçlü ayar:
    • "recovery"
    • "bootloader"
  • blunt set:
    • "cold". Genellikle bellek dahil tüm cihazların tamamen sıfırlandığını gösterir.
    • "hard". Genellikle donanımın durumunun sıfırlandığını ve ramoops'in kalıcı içeriği koruyacağını gösterir.
    • "warm". Genellikle belleğin ve cihazların bazı durumları koruduğunu, ramoops (bkz. çekirdekteki pstore sürücü) yedek deposunun ise kalıcı içerik barındırdığını gösterir.
    • "shutdown"
    • "reboot". Genellikle ramoops durumunun ve donanım durumunun bilinmediği anlamına gelir. cold, hard ve warm değerleri cihaz sıfırlama işleminin derinliği hakkında ipuçları sağladığından bu değer geniş kapsamlıdır.

Önyükleme yükleyiciler bir çekirdek grubu veya düz grup reason sağlamalıdır ve belirlenebiliyorsa subreason sağlaması önemle tavsiye edilir. Örneğin, ramoops yedeği olup olmayabileceği uzun basılan güç düğmesi için "reboot,longkey" önyükleme nedeni olur.

Hiçbir ilk span reason, subreason veya detail'nin parçası olamaz. Bununla birlikte, çekirdek grubu nedenleri kullanıcı alanı tarafından üretilemeyeceğinden "watchdog", künt olarak ayarlanan bir nedenden sonra kaynağın ayrıntısıyla (örneğin, "reboot,watchdog,service_manager_unresponsive" veya "reboot,software,watchdog") tekrar kullanılabilir.

Açılış nedenlerinin anlaşılması için uzman düzeyinde şirket içi bilgi gerekmemelidir ve/veya sezgisel bir raporla kullanıcılar tarafından okunabilir olmalıdır. Örnekler: "shutdown,vbxd" (kötü), "shutdown,uv" (daha iyi), "shutdown,undervoltage" (tercih edilen).

Neden-alt neden kombinasyonları

Android, normal kullanımda aşırı yüklenmemesi gereken ancak kombinasyon ilişkili durumu doğru yansıtıyorsa duruma göre kullanılabilecek bir dizi reason-subreason kombinasyonu ayırır. Ayrılmış kombinasyonlara örnek olarak aşağıdakiler verilebilir:

  • "reboot,userrequested"
  • "shutdown,userrequested"
  • "shutdown,thermal" (thermald tarafından)
  • "shutdown,battery"
  • "shutdown,battery,thermal" (BatteryStatsService tarafından)
  • "reboot,adb"
  • "reboot,shell"
  • "reboot,bootloader"
  • "reboot,recovery"

Daha fazla bilgi için system/core/bootstat/bootstat.cpp'daki kBootReasonMap dosyasını ve Android kaynak deposundaki ilişkili git changelog geçmişini inceleyin.

Başlatma nedenlerini raporla

Önyükleme nedenlerinin tümü (önyükleme yükleyiciden veya standart önyükleme nedeni olarak kaydedilenler) system/core/bootstat/bootstat.cpp dosyasının kBootReasonMap bölümüne kaydedilmelidir. kBootReasonMap listesi, uyumlu ve eski uyumlu olmayan nedenlerin bir karışımıdır. Bootloader geliştiricileri buraya yalnızca yeni uyumlu nedenleri kaydetmelidir (ve ürün daha önce gönderilmiş ve değiştirilemediği sürece uyumlu olmayan nedenler kaydetmemelidir).

system/core/bootstat/bootstat.cpp'de mevcut, uyumlu girişleri kullanmanızı ve uyumlu olmayan bir dize kullanmadan önce dikkatli olmanızı önemle tavsiye ederiz. Yönerge olarak şu şekildedir:

  • bootstat, alt nedenleri standart system_boot_reason_prop içinde ayrıntılandırmak amacıyla kernel_panic signatures için ramoops öğesini inceleyebilir. Bu nedenle, bootloader'dan "kernel_panic" dosyasını bildirmek için tamam.
  • kBootReasonMap'de uyumlu olmayan bir dizenin bildirilmesi Tamam değildir (ör. bootloader'daki "panic")). Bu, reason'i hassaslaştırma özelliğini bozar.

Örneğin, kBootReasonMap alanında "wdog_bark" varsa bootloader geliştiricisi:

  • "watchdog,bark" olarak değiştirin ve kBootReasonMap bölgesindeki listeye ekleyin.
  • "bark"'ün teknolojiyle aşina olmayanlar için ne anlama geldiğini düşünün ve daha anlamlı bir subreason'ün kullanılıp kullanılamayacağını belirleyin.

Başlatma nedeni uygunluğunu doğrulayın

Şu anda Android, bir önyükleyicinin sağlayabileceği tüm olası önyükleme nedenlerini doğru bir şekilde tetikleyebilen veya inceleyebilecek etkin bir CTS testi sunmamaktadır. Bununla birlikte, iş ortakları uyumluluğu belirlemek için pasif bir test çalıştırmayı deneyebilir.

Bu nedenle, önyükleme yöneticisi uyumluluğu, önyükleme yöneticisi geliştiricilerinin yukarıda açıklanan kuralların ve yönergelerin ruhuna gönüllü olarak uymasını gerektirir. Bu tür geliştiricileri AOSP'ye (özellikle system/core/bootstat/bootstat.cpp'e) katkıda bulunmaya ve bu fırsatı, önyükleme nedeni sorunlarıyla ilgili tartışmalar için bir forum olarak kullanmaya çağırıyoruz.