Android 7.0, RIL işlevselliğini iyileştirmek için bir dizi özellik kullanarak Radyo Arayüz Katmanı'nı (RIL) yeniden düzenledi. Bu özellikleri uygulamak için iş ortağı kodu değişiklikleri yapılması gerekir. Bu özellikler isteğe bağlıdır ancak kullanılması önerilir. Yeniden düzenleme değişiklikleri geriye dönük olarak uyumludur. Bu nedenle, yeniden düzenlenmiş özelliklerin önceki uygulamaları çalışmaya devam eder.
RIL yeniden düzenlemesi aşağıdaki iyileştirmeleri içerir:
- RIL hata kodları. Mevcut
GENERIC_FAILUREkoduna ek olarak belirli hata kodlarını etkinleştirir. Bu, hataların nedenleri hakkında daha ayrıntılı bilgi vererek hatalarla ilgili sorunları gidermeye yardımcı olur. - RIL sürümü oluşturma. Daha doğru ve kolay yapılandırılabilen sürüm bilgileri sağlar.
- Wakelock'ları kullanarak RIL iletişimi. Cihazın pil performansını artırır.
Yukarıdaki iyileştirmelerin birini veya tümünü uygulayabilirsiniz. Daha fazla bilgi için https://android.googlesource.com/platform/hardware/ril/+/android16-release/include/telephony/ril.h adresindeki RIL sürüm oluşturma ile ilgili kod yorumlarına bakın.
Gelişmiş RIL hata kodlarını uygulama
Neredeyse 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ıtlarda görülen bir sorundur. Aynı GENERIC_FAILURE hata kodu, farklı nedenlerle RIL çağrıları tarafından döndürülürse hata raporundaki bir sorunun hata ayıklamasını zorlaştırabilir. Satıcıların, kodun hangi bölümünün GENERIC_FAILURE kodu döndürmüş olabileceğini belirlemesi bile önemli ölçüde 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 ayrı 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 olarak eşlenmiş ayrı bir tam sayı grubu (ör. 1 ile x) olarak döndürebilir. Sağlayıcılar, döndürülen her bir maskelenmiş hata kodunun koddaki benzersiz bir hata nedenine karşılık geldiğinden emin olmalıdır. Belirli hata kodlarının kullanılması, OEM tarafından genel hatalar döndürüldüğünde RIL hata ayıklama işlemini hızlandırabilir. Bunun nedeni, GENERIC_FAILURE hata kodunun tam olarak nedenini belirlemenin genellikle çok uzun sürmesi (ve bazen de bunu anlamanın imkansız olmasıdır).
Ayrıca, ril.h, enum'lar için daha fazla hata kodu ekler
RIL_LastCallFailCause ve RIL_DataCallFailCause böylece
satıcı kodu, CALL_FAIL_ERROR_UNSPECIFIED ve PDP_FAIL_ERROR_UNSPECIFIED gibi genel hatalar döndürmekten kaçınabilir.
Gelişmiş RIL hata kodlarını doğrulama
GENERIC_FAILURE kodunun yerine yeni hata kodları ekledikten sonra, yeni hata kodlarının GENERIC_FAILURE yerine RIL çağrısı tarafından döndürüldüğünü doğrulayın.
Gelişmiş RIL sürüm oluşturmayı uygulama
Eski Android sürümlerinde RIL sürümü oluşturma sorunluydu: Sürümün kendisi kesin değildi, RIL sürümünü bildirme mekanizması net değildi (bazı satıcıların yanlış sürüm bildirmesine neden oluyordu) ve sürümü tahmin etmeye yönelik geçici çözümde yanlışlıklar olabiliyordu.
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. RIL sürümüne karşılık gelen değişiklikler yaparken tedarikçiler, kodda sürümlerini güncellemeli ve bu sürümü RIL_REGISTER içinde döndürmelidir.
Gelişmiş RIL sürüm oluşturmayı doğrulama
RIL_REGISTER sırasında RIL kodunuza karşılık gelen RIL sürümünün (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ış uyandırma kilitleri, RIL iletişiminde yanlış bir şekilde kullanılıyor. Bu durum, pil performansını olumsuz etkiliyor. Android 7.x ve sonraki sürümlerde, RIL isteklerini sınıflandırarak ve kodu, farklı istek türleri için uyandırma kilitlerini farklı şekilde işleyecek şekilde güncelleyerek performansı artırabilirsiniz.
RIL isteklerini sınıflandırma
RIL istekleri istenmiş veya istenmemiş olabilir. Tedarikçiler, istenen istekleri aşağıdakilerden biri olarak sınıflandırmalıdır:
- eşzamanlı. Yanıtlanması uzun sürmeyen istekler. Örneğin,
RIL_REQUEST_GET_SIM_STATUS. - asynchronous. Yanıtlanması uzun zaman alan istekler. Örneğin,
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.
Asenkron olarak istenen RIL istekleri önemli ölçüde zaman alabilir. RIL Java, satıcı kodundan onay aldıktan sonra wakelock'u serbest bırakır. Bu durum, uygulama işlemcisinin boşta durumdan askıya alma durumuna geçmesine neden olabilir. Satıcı kodundan yanıt alındığında RIL Java (uygulama işlemcisi) wakelock'u yeniden alır, yanıtı işler ve ardından boşta duruma döner. Bu tür boşta modundan askıya alma moduna ve tekrar boşta moduna geçişler çok fazla güç tüketebilir.
Yanıt süresi yeterince uzun değilse wakelock'u tutmak ve yanıt vermek için gereken süre boyunca boşta kalmak, wakelock'u serbest bırakıp yanıt geldiğinde uyanarak askıya alma durumuna geçmekten daha az güç tüketir. Tedarikçiler, tüm süre boyunca T boşta kalırken tüketilen güç, aynı süre T içinde boşta kalma durumundan askıya alma durumuna ve tekrar boşta kalma durumuna geçiş yaparken tüketilen güçten daha fazla olduğunda T süresinin eşik değerini belirlemek için platforma özgü güç ölçümlerini kullanmalıdır. Zaman T bilindiğinde, zaman T değerinden daha uzun süren RIL komutları eşzamansız, kalan komutlar ise eşzamanlı olarak sınıflandırılabilir.
RIL iletişim senaryoları
Aşağıdaki şemalarda, yaygın RIL iletişim senaryoları gösterilmekte ve RIL'den istenen ve istenmeyen istekleri işlemek için kodun nasıl değiştirileceğine dair çözümler sunulmaktadır.
Not: Aşağıdaki diyagramlarda kullanılan işlevlerle ilgili uygulama ayrıntıları için acquireWakeLock(), decrementWakeLock() ve clearWakeLock( yöntemlerine bakın (ril.cpp).
Senaryo: RIL isteği ve istenen eşzamansız yanıt
Bu senaryoda, RIL'den istenen yanıtın önemli ölçüde zaman alması bekleniyorsa (ör. RIL_REQUEST_GET_AVAILABLE_NETWORKS yanıtı), uygulama işlemcisi tarafında wakelock uzun süre tutulur. Modem sorunları da uzun süre beklemenize neden olabilir.
1. çözüm: Modem, RIL isteği ve eşzamansız yanıt için uyandırma kilidini tutuyor.
- RIL isteği gönderilir ve modem, bu isteği işlemek için uyandırma kilidi alır.
- Modem, Java tarafının uyanık kalma kilidi sayacını azaltmasına ve sayaç değeri 0 olduğunda kilidi serbest bırakmasına neden olan bir onay gönderir.
Not: İstek-onay sırası için wakelock zaman aşımı süresi, onay oldukça hızlı bir şekilde alınması gerektiğinden şu anda kullanılan zaman aşımı süresinden daha kısa olacaktır.
- Modem, isteği işledikten sonra wakelock'u alan ve ril.cpp'ye yanıt gönderen satıcı koduna bir kesme gönderir. Bu kod da wakelock'u alıp Java tarafına yanıt gönderir.
- Yanıt Java tarafına ulaştığında wakelock alınır ve arayana yanıt döndürülür.
- Yanıt tüm modüller tarafından işlendikten sonra
ril.cpp'ya (soket üzerinden) onay gönderilir.ril.cppda 3. adımda alınan uyandırma kilidini serbest bırakır.
2. çözüm: Modem, uyandırma kilidini tutmuyor ve yanıt hızlı (eşzamanlı RIL isteği ve yanıtı). Eşzamanlı ve eşzamansız davranış, belirli bir RIL komutu için sabit kodlanmıştır ve her arama için ayrı ayrı belirlenir.
- RIL isteği, Java tarafında
acquireWakeLock()çağrılarak gönderilir. - Tedarikçi kodunun uyanık kalma kilidi alması gerekmez ve isteği işleyip hızlı bir şekilde yanıtlayabilir.
- Yanıt Java tarafına ulaştığında,
decrementWakeLock()çağrılır. Bu işlev, wakelock sayacını azaltır ve sayaç değeri 0 ise wakelock'u serbest bırakır.
Senaryo: RIL istenmeyen yanıtı
Bu senaryoda, RIL'nin istenmeyen yanıtlarında, satıcı yanıtı için wakelock alınması gerekip gerekmediğini belirten bir wakelock türü işareti bulunur. İşaret ayarlanırsa zamanlanmış bir wakelock ayarlanır ve yanıt, Java tarafına bir soket üzerinden gönderilir. Zamanlayıcı süresi dolduğunda uyandırma kilidi serbest bırakılır. Zamanlanmış uyandırma kilidi, farklı RIL istenmeyen yanıtları için çok uzun veya çok kısa olabilir.
Çözüm: İstenmeyen bir yanıt gönderilirken yerel tarafta zamanlanmış bir wakelock tutmak yerine Java kodundan yerel tarafa (ril.cpp) bir onay gönderilir.
Yeniden tasarlanan uyanık kalma kilitlerini doğrulama
RIL çağrılarının senkron veya asenkron olarak tanımlandığını doğrulayın. Pil gücü tüketimi donanıma/platforma bağlı olabileceğinden, tedarikçiler, eşzamansız aramalar için yeni wakelock semantiğini kullanmanın pil gücünde tasarruf sağlayıp sağlamadığını öğrenmek için bazı dahili testler yapmalıdır.