Standart başlatma nedeni

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

Başlatma nedenleri

Bootloader, aşağıdaki işlemleri gerçekleştirmek için benzersiz bir şekilde kullanılabilen donanım ve bellek kaynaklarını kullanır: bir cihazın neden yeniden başlatıldığını belirler, ardından androidboot.bootreason=<reason> Android'e ekleniyor kernel komut satırını kullanın. init, daha sonra bunu çevirir komut satırı ile Android mülkündeki tüm cihazlarınıza bootloader_boot_reason_prop (ro.boot.bootreason). Android 12 veya sonraki sürümlerin yüklü olduğu cihazlarda 5.10 veya daha yeni çekirdek sürümü kullanıldığında, androidboot.bootreason=<reason> , çekirdek komut satırı yerine bootconfig'e eklenir.

Başlatma nedeni özellikleri

Android'in önceki sürümleri, boşluklar, tamamı küçük harfle yazıldı, birkaç gereksinim (ör. raporlama için kernel_panic, watchdog, cold/warm/hard) ve başka benzersiz sebeplerden dolayı ödemeler. Bu belirsiz spesifikasyon yüzlerce özel (ve bazen anlamsız) başlatma nedeninin çoğalması Bu da yönetilemeyen bir duruma yol açıyordu. Şu anki Android sürümü, neredeyse ayrıştırılamayan veya anlamsız içeriğin büyük ivmesi dosyası, Bootloader tarafından dosyalanan ve bootloader_boot_reason_prop

Android 9 sürümüyle birlikte Android ekibi , eski bootloader_boot_reason_prop sürümünün önemli bir hıza sahiptir ve çalışma zamanında yeniden yazılamaz. Projenin yaşam döngüsü Dolayısıyla başlatma nedeni spesifikasyonu, bootloader'ını geliştirip mevcut sistemde rötuşlar yapın. Bunun için Android ekibi:

• Bootloader geliştiricilerini aşağıdakileri yapmaya teşvik etmek için onlarla işbirliği yapma:
  • ve anlaşılması gereken standart, ayrıştırılabilir ve anlaşılması bootloader_boot_reason_prop
  • system/core/bootstat/bootstat.cpp etkinliğine katılın kBootReasonMap listesi.
• system_boot_reason_prop (sys.boot.reason). CEVAP sınırlı bir sistem uygulaması grubu (ör. bootstat ve init) bu özelliği yeniden yazabilir, ancak tüm uygulamalar okuması için sepolicy haklarını verdi.
• Başlatma nedeni hakkında kullanıcıları, kullanıcı verileri eklenene kadar beklemeleri gerektiği konusunda bilgilendirme sistem başlatma nedeni özelliğindeki içeriğe güvenmeden önce system_boot_reason_prop

Neden bu kadar geç? bootloader_boot_reason_prop erken kullanıma sunulacak Android güvenlik politikası uyarınca gerektiğinde engellenir. çünkü yanlış, ayrıştırılamayan ve standart olmayan bilgileri temsil eder. Çoğu durumda, yalnızca başlatma sistemi hakkında derinlemesine bilgi sahibi olan geliştiriciler bu bilgilere erişmesi gerekir. Hassaslaştırılmış, ayrıştırılabilir ve standart system_boot_reason_prop ile başlatma nedeni için API güvenilir ve yalnızca kullanıcı verileri eklendikten sonra doğru şekilde alınır. Özellikle:

• Kullanıcı verileri eklenmeden önce, system_boot_reason_prop, şuradan değeri içerecek: bootloader_boot_reason_prop.
• Kullanıcı verileri eklendikten sonra system_boot_reason_prop, politikaya uygun veya raporlayın.

Bu nedenle Android 9, Bu nedenle, başlatma nedeni resmi olarak edinilmeden önce açılışta anında doğru sonuç verir (bootloader_boot_reason_prop ile) eklendikten sonra kullanılabilir hale gelecek şekilde ( system_boot_reason_prop) tıklayın.

Bootstat mantığı, daha bilgilendirici ve uyumlu bir sisteme bağlıdır. bootloader_boot_reason_prop Bu mülkte bir Böylece, tüm kontrollü yeniden başlatma işlemlerinin doğruluğunu artırır ve doğru bir şekilde Bu da senaryonun doğruluğunu ve anlamını geliştirip genişletmesini sağlar. / system_boot_reason_prop.

Standart başlatma nedeni biçimi

bootloader_boot_reason_prop için standart başlatma nedeni biçimi , Android 9'da aşağıdaki söz dizimini kullanır:

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

Biçimlendirme kuralları:

• Küçük harf
• Boşluk kullanmayın (alt çizgi kullanın)
• Yazdırılabilir tüm karakterler
• Virgülle ayrılmış reason, subreason ve bir veya detail örneği daha.
  • En yüksek önceliği temsil eden zorunlu bir reason cihazın yeniden başlatılması veya kapatılmasının nedeni.
  • Kısa bir özetini temsil eden isteğe bağlı subreason cihazın yeniden başlatılması veya kapatılması (ya da kim tarafından yeniden başlatılması veya cihazda) olduğunu varsayalım.
  • İsteğe bağlı olarak bir veya daha fazla detail değeri. detail bir alt sisteme işaret ederek belirli bir sistemin hangi sistem subreason ile sonuçlandı. Birden çok öğe belirtebilirsiniz Genellikle şu hiyerarşiyi izlemesi gereken detail değerleri: önem taşır. Bununla birlikte, dilerseniz Eşit önem düzeyine sahip detail değerleri.

bootloader_boot_reason_prop için boş bir değer dikkate alınır yasa dışıdır (bu, diğer aracıların olaydan sonra bir başlatma nedeni yerleştirmesine olanak tanır).

Neden şartları

reason için sağlanan değer (ilk aralık, fesihten önce veya virgül), aşağıdaki küme çekirdek, güçlü ve künt olarak ayrılmış olmalıdır. nedenler:

• çekirdek kümesi:
  • "watchdog"
  • "kernel_panic"
• güçlü küme:
  • "recovery"
  • "bootloader"
• künt olarak ayarlandı:
  • "cold" Genellikle tüm cihazların tamamen sıfırlandığını gösterir. hafıza da buna dahildir.
  • "hard" Genellikle donanımın kendi durumunun olduğunu gösterir sıfırlama işlemi yapılır ve ramoops kalıcı içeriği saklamalıdır.
  • "warm" Genel olarak belleği ve cihazları gösterir bazı eyaletler ve ramoops korunur (bkz. pstore yedek deposunda kalıcı içerik bulunur.
  • "shutdown"
  • "reboot" Genellikle ramoops durumunun şöyle olduğu anlamına gelir: cihazın durumu bilinmiyor. Bu değer, cold, hard ve warm değerleri sağlar sıfırlama işleminin derinliği hakkında ipuçları verir.

Bootloader'lar bir çekirdek grubu veya bir kört küme reason sağlamalıdır ve mümkünse bir subreason sağlanması önerilir belirler. Örneğin, güç tuşuna uzun basmak zorunda kalabilirsiniz. Başlatma nedeni ramoops yedeğinde olabilir "reboot,longkey".

İlk aralık reason, herhangi bir subreason veya detail. Ancak, çekirdek tarafından ayarlanan nedenler "watchdog", belirgin bir nedenden sonra yeniden kullanılabilir. kaynağın bir ayrıntısıyla (örneğin, "reboot,watchdog,service_manager_unresponsive" veya "reboot,software,watchdog").

Başlatma nedenleri, verileri çözmek ve/veya anlaşılması kolay bir raporla okunabilir olmalıdır. Örnekler: "shutdown,vbxd" (kötü), "shutdown,uv" (daha iyi), "shutdown,undervoltage" (tercih edilen).

Neden-alt neden kombinasyonları

Android reason-subreason arasında rezervasyon yapar normal kullanımda aşırı yüklenmemesi gereken ancak duruma göre, kombinasyon, ilişkili reklamı doğru yansıtıyorsa koşul alır. Ayrılmış kombinasyonlara örnekler:

• "reboot,userrequested"
• "shutdown,userrequested"
• "shutdown,thermal" (thermald dilinden)
• "shutdown,battery"
• "shutdown,battery,thermal" (en yüksek fiyat: BatteryStatsService)
• "reboot,adb"
• "reboot,shell"
• "reboot,bootloader"
• "reboot,recovery"

Daha ayrıntılı bilgi için kBootReasonMap bölümüne bakın system/core/bootstat/bootstat.cpp ve ilişkili git değişiklik günlüğü geçmişini görebilirsiniz.

Başlatma nedenlerini raporla

Bootloader'dan gelen veya standart başlatmada kaydedilen tüm başlatma nedenleri kBootReasonMap bölümüne kaydedilmelidir. system/core/bootstat/bootstat.cpp. İlgili içeriği oluşturmak için kullanılan kBootReasonMap listesi, uyumlu ve eski öğelerin bir karışımıdır neden olabilir. Bootloader geliştiricileri yalnızca yeni burada belirtilen kurallara uygun olmayan nedenler ürün daha önce gönderilmiş ve değiştirilemez).

Google Etiket Yöneticisi'nde mevcut, uyumlu girişleri kullanmanızı system/core/bootstat/bootstat.cpp ve öncesinde kısıtlama egzersizleri yapın dizeleri kullanmaktır. Yönerge olarak şu şekildedir:

• Tamam'ı tıklayarak "kernel_panic" adlı kişiyi bootloader'ı yükleyin, bootstat bunu inceleyebilir daraltmak için kernel_panic signatures için ramoops alt nedenleri standart system_boot_reason_prop bölümüne ekleyin.
• Uyumlu olmayan bir dizeyi bildirmek için Uygun Değil kBootReasonMap (örneğin "panic") bootloader'ı yükleyin, bu durum sonuçta reason.

Örneğin, kBootReasonMap "wdog_bark" içeriyorsa bir bootloader geliştiricisi şunları yapmalıdır:

• "watchdog,bark" olarak değiştirin ve şuradaki listeye ekleyin: kBootReasonMap.
• "bark" özelliğinin, ve subreason ürününün daha anlamlı olup olmadığını kullanılabilir.

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

Şu anda Android, doğru sonuçları verebilecek etkin bir CTS testi sağlamamaktadır. bir bootloader'ın sağlayabileceği tüm olası başlatma nedenlerini tetikleme veya inceleme; iş ortakları, uyumluluğu belirlemek için pasif test yapmayı deneyebilir.

Sonuç olarak, bootloader uyumluluğu için bootloader geliştiricilerinin yukarıda açıklanan kuralların ve yönergelerin ruhuna gönüllü olarak uygun hareket etmelisiniz. Bu tür geliştiricilerin AOSP'ye (özellikle de Google'ın system/core/bootstat/bootstat.cpp) ve bu fırsatı aşağıdaki hakkındaki tartışmalar için foruma Google'dan erişebilirsiniz.