RIL'yi yeniden düzenleme

Android 7.0, RIL işlevini iyileştirmek için bir dizi özellik kullanarak Radyo Arayüzü Katmanı'nı (RIL) yeniden yapılandırdı. Bu özellikleri uygulamak için iş ortağı kod değişiklikleri gerekir. Bu değişiklikler isteğe bağlıdır ancak önerilir. Yeniden yapılandırmaya yönelik değişiklikler geriye dönük uyumlu olduğundan, yeniden yapılandırılmış özelliklerin önceki uygulamaları çalışmaya devam eder.

RIL yeniden yapılandırması aşağıdaki iyileştirmeleri içerir:

  • RIL hata kodları. Mevcut GENERIC_FAILURE koduna ek olarak belirli hata kodlarını etkinleştirir. Bu, hataların nedeni hakkında daha ayrıntılı bilgi sağlayarak hata giderme işlemine yardımcı olur.
  • RIL sürümü oluşturma. Daha doğru ve yapılandırması daha kolay sürüm bilgileri sağlar.
  • Uyanma kilitlerini kullanan RIL iletişimi. Cihazın pil performansını iyileştirir.

Yukarıdaki iyileştirmelerin tümünü veya bir kısmını uygulayabilirsiniz. Daha fazla bilgi için https://android.googlesource.com/platform/hardware/ril/+/main/include/telephony/ril.h'teki RIL sürüm oluşturma ile ilgili kod yorumlarına bakın.

Gelişmiş RIL hata kodlarını uygulama

Hemen hemen tüm RIL istek çağrıları, bir hataya yanıt olarak GENERIC_FAILURE hata kodunu döndürebilir. Bu, OEM'ler tarafından döndürülen tüm istenen yanıtlarla ilgili bir sorundur. RIL çağrıları farklı nedenlerle aynı GENERIC_FAILURE hata kodunu döndürüyorsa hata raporundan sorunla ilgili hata ayıklama işlemini zorlaştırabilir. Tedarikçi firmaların, kodun hangi bölümünün GENERIC_FAILURE kodu döndürmüş olabileceğini belirlemesi bile çok zaman alabilir.

Android 7.x ve sonraki sürümlerde OEM'ler, şu anda GENERIC_FAILURE olarak sınıflandırılan her farklı hatayla ilişkili farklı bir hata kodu değeri döndürebilir. Özel hata kodlarını herkese açık olarak göstermek istemeyen OEM'ler, hataları OEM_ERROR_1 ile OEM_ERROR_X arasında eşlenen farklı bir tam sayı grubu (ör. 1 ila x) olarak döndürebilir. Tedarikçi firmalar, döndürülen her maskelenmiş hata kodunun koddaki benzersiz bir hata nedeniyle eşleştiğinden emin olmalıdır. GENERIC_FAILURE hata kodunun tam nedenini belirlemek genellikle çok zaman alabileceğinden (ve bazen bu nedenin belirlenmesi imkansız olduğundan) OEM tarafından genel hatalar döndürüldüğünde belirli hata kodlarının kullanılması RIL hata ayıklama işlemini hızlandırabilir.

Ayrıca ril.h, tedarikçi kodu CALL_FAIL_ERROR_UNSPECIFIED ve PDP_FAIL_ERROR_UNSPECIFIED gibi genel hataları döndürmemek için RIL_LastCallFailCause ve RIL_DataCallFailCause enum'leri için daha fazla hata kodu ekler.

Gelişmiş RIL hata kodlarını doğrulama

GENERIC_FAILURE kodunun yerine yeni hata kodları ekledikten sonra, GENERIC_FAILURE yerine RIL çağrısı tarafından yeni hata kodlarının döndürüldüğünü doğrulayın.

Gelişmiş RIL sürümlendirmesini uygulama

Eski Android sürümlerindeki RIL sürümlendirmesi sorunluydu: Sürümün kendisi kesin değildi, RIL sürümünü bildirme mekanizması net değildi (bazı tedarikçilerin yanlış sürüm bildirmesine neden oluyordu) ve sürümü tahmin etmeye yönelik geçici çözüm yanlışlığa açıktı.

Android 7.x ve sonraki sürümlerde ril.h, tüm RIL sürüm değerlerini belgeler, ilgili RIL sürümünü açıklar ve bu sürümle ilgili tüm değişiklikleri listeler. Tedarikçi firmalar, RIL sürümüne karşılık gelen değişiklikler yaparken sürümlerini kodda güncellemeleri ve RIL_REGISTER içinde döndürmeleri gerekir.

Gelişmiş RIL sürüm oluşturma özelliğini doğrulama

RIL kodunuza karşılık gelen RIL sürümünün RIL_REGISTER sırasında (ril.h içinde tanımlanan RIL_VERSION yerine) döndürüldüğünü doğrulayın.

Wakelock'ları kullanarak RIL iletişimini uygulama

Zamanlanmış wakelock'lar, RIL iletişiminde hatalı bir şekilde kullanılıyor. Bu da pil performansını olumsuz yönde etkiliyor. Android 7.x ve sonraki sürümlerde, RIL isteklerini sınıflandırarak ve kodu farklı istek türleri için wakelock'ları farklı şekilde ele alacak şekilde güncelleyerek performansı artırabilirsiniz.

RIL isteklerini sınıflandırma

RIL istekleri istek üzerine veya isteksiz olarak gönderilebilir. Tedarikçiler, istenen istekleri aşağıdakilerden biri olarak sınıflandırmalıdır:

  • eşzamanlı. Yanıtlanması çok fazla zaman almayan istekler. Örneğin, RIL_REQUEST_GET_SIM_STATUS.
  • asynchronous. Yanıtlanması uzun süren istekler. Örneğin, RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.

İsteğe bağlı asenkron RIL istekleri oldukça uzun sürebilir. RIL Java, tedarikçi kodundan bir onay aldıktan sonra wakelock'u serbest bırakır. Bu, uygulama işlemcisinin boş durumdan askıya alınmış duruma geçmesine neden olabilir. Yanıt tedarikçi kodundan alınabildiğinde RIL Java (uygulama işlemcisi) uyandırıcı kilidi yeniden alır, yanıtı işler ve ardından boşta durumuna döner. Bu tür işlemler (boş durumdan askıya alma durumuna ve ardından tekrar boş duruma geçme) çok fazla güç tüketebilir.

Yanıt süresi yeterince uzun değilse uyanık tutma kilidini basılı tutmak ve yanıtın gelmesi için geçen süre boyunca boşta kalmak, uyanık tutma kilidini bırakarak askıya alma durumuna geçmekten ve yanıt geldiğinde uyandırmaktan daha enerji verimli olabilir. Tedarikçiler, T süresi boyunca boşta kalarak tüketilen gücün T süresi boyunca boşta kalarak ve aynı zamanda beklemeye alarak tüketilen güçten daha fazla olduğu T zaman eşiği değerini belirlemek için platforma özgü güç ölçümlerini kullanmalıdır. T zamanı bilindiğinde, T zamanından daha uzun süren RIL komutları eşzamansız olarak, geri kalan komutlar ise eşzamanlı olarak sınıflandırılabilir.

RIL iletişim senaryoları

Aşağıdaki şemalar, yaygın RIL iletişim senaryolarını gösterir ve RIL'den istenen ve istenmeyen istekleri işlemek için kodu değiştirmeye yönelik çözümler sunar.

Not: Aşağıdaki şemalarda kullanılan işlevlerle ilgili uygulama ayrıntıları için ril.cpp'deki acquireWakeLock(), decrementWakeLock() ve clearWakeLock( yöntemlerine bakın.

Senaryo: RIL isteği ve istenen eşzamansız yanıt

Bu senaryoda, RIL'den istenen yanıtın önemli ölçüde zaman almasının (ör. RIL_REQUEST_GET_AVAILABLE_NETWORKS için bir yanıt) beklenmesi durumunda, uyanık tutma işlemi uygulama işlemcisi tarafında uzun süre boyunca tutulur. Modem sorunları da uzun süre beklemenize neden olabilir.

Şekil 1. RIL, eşzamansız yanıt istedi.

1. Çözüm: Modem, RIL isteği ve asenkron yanıt için uyanık tutma durumunu korur.

Şekil 2. Modem tarafından tutulan uyandırma kilidi.
  1. RIL isteği gönderilir ve modem bu isteği işlemek için wakelock'u edinir.
  2. Modem, Java tarafının wakelock sayacını azaltmasına ve sayaç değeri 0 olduğunda onu serbest bırakmasına neden olan bir onay gönderir.

    Not: Onay oldukça hızlı bir şekilde alınacağından, istek-onay sırası için uyandırıcı kilitlenme zaman aşımı süresi, şu anda kullanılan zaman aşımı süresinden daha kısa olur.

  3. Modem, isteği işledikten sonra tedarikçi koduna bir kesinti gönderir. Bu kod, wakelock'u alır ve ril.cpp'ye yanıt gönderir. ril.cpp de wakelock'u alır ve Java tarafına yanıt gönderir.
  4. Yanıt Java tarafına ulaştığında wakelock elde edilir ve arayana bir yanıt döndürülür.
  5. Yanıt tüm modüller tarafından işlendikten sonra, onay ril.cpp'e (soket üzerinden) geri gönderilir. ril.cpp, 3. adımda edinilen wakelock'u serbest bırakır.

2. Çözüm: Modem, uyanık tutma işlemini yapmaz ve yanıt hızlıdır (eşzamanlı RIL isteği ve yanıtı). Senkronize ve asynkron davranış, belirli bir RIL komutu için sabit kodlanır ve çağrı bazında karar verilir.

Şekil 3. Uyandırma kilidi modem tarafından tutulmuyor.
  1. RIL isteği, Java tarafında acquireWakeLock() çağrılarak gönderilir.
  2. Tedarikçi kodunun wakelock edinmesi gerekmez ve isteği işleyip hızlı bir şekilde yanıt verebilir.
  3. Yanıt Java tarafına ulaştığında decrementWakeLock() çağrılır. Bu işlev, uyanık tutma sayacını azaltır ve sayaç değeri 0 ise uyanık tutmayı serbest bırakır.

Senaryo: İstenmeyen RIL yanıtı

Bu senaryoda, RIL isteksiz yanıtlarında tedarikçi yanıtı için wakelock'un edinilmesi gerekip gerekmediğini belirten bir wakelock türü işareti bulunur. İşaretçi ayarlanırsa zamanlı bir uyandırıcı kilit ayarlanır ve yanıt, bir soket üzerinden Java tarafına gönderilir. Zamanlayıcının süresi dolduğunda uyandırıcı kilidi kaldırılır. Zamanlanmış uyandırıcı, farklı RIL isteksiz yanıtları için çok uzun veya çok kısa olabilir.

Şekil 4. RIL istenmeyen yanıtı.

Çözüm: İstenmeyen bir yanıt gönderirken yerel tarafta zamanlanmış bir uyanma kilidi tutmak yerine Java kodundan yerel tarafa (ril.cpp) bir onay gönderilir.

Şekil 5. Zamanlanmış uyandırıcı kilit yerine ack kullanılması.

Yeniden tasarlanmış uyandırıcı kilitleri doğrulama

RIL çağrılarının senkron veya asenkron olarak tanımlandığını doğrulayın. Pil güç tüketimi donanıma/platforma bağlı olabileceğinden, tedarikçi firmalar, asenkron çağrılar için yeni wakelock semantiğini kullanmanın pil tasarrufu sağlayıp sağlamadığını öğrenmek üzere bazı dahili testler yapmalıdır.