Bu sayfa, Cloud Translation API ile çevrilmiştir.

RIL Yeniden Düzenleme

Android 7.0, RIL işlevselliğini geliştirmek için bir dizi özellik kullanarak Radyo Arayüzü Katmanını (RIL) yeniden düzenledi. İsteğe bağlı ancak teşvik edilen bu özelliklerin uygulanması için iş ortağı kodu değişiklikleri gereklidir. Yeniden düzenleme değişiklikleri geriye dönük olarak uyumludur, dolayısıyla yeniden düzenlenen özelliklerin önceki uygulamaları çalışmaya devam eder.

RIL yeniden düzenlemesi 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 spesifik bilgiler sağlayarak hata gidermeye yardımcı olur.
RIL versiyonlaması. Sürüm bilgilerini yapılandırmak için daha doğru ve daha kolay sağlar.
Wakelock'ları kullanarak RIL iletişimi. Cihazın pil performansını artırır.

Yukarıdaki iyileştirmelerin herhangi birini veya tümünü uygulayabilirsiniz. Daha fazla ayrıntı için https://android.googlesource.com/platform/hardware/ril/+/main/include/telephony/ril.h adresindeki RIL sürümü oluşturmayla ilgili kod yorumlarına bakın.

Gelişmiş RIL hata kodlarının uygulanması

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 talep edilen yanıtlarla ilgili bir sorundur ve farklı nedenlerle RIL çağrıları tarafından aynı GENERIC_FAILURE hata kodunun döndürülmesi durumunda, hata raporundan bir sorunda hata ayıklamayı zorlaştırabilir. Satıcıların, kodun hangi bölümünün bir GENERIC_FAILURE kodu döndürdüğünü belirlemeleri bile oldukça zaman alabilir.

Android 7.x ve sonraki sürümlerde, OEM'ler şu anda GENERIC_FAILURE olarak kategorize edilen her farklı hatayla ilişkili ayrı bir hata kodu değeri döndürebilir. Özel hata kodlarını genel olarak açıklamak istemeyen OEM'ler, hataları OEM_ERROR_1 ile OEM_ERROR_X arasında eşlenen ayrı bir tam sayı kümesi (1'den x'e kadar) olarak döndürebilir. Satıcılar, bu tür maskelenmiş hata kodlarının her birinin, koddaki benzersiz bir hata nedeni ile eşlemeler döndürdüğünden emin olmalıdır. Belirli hata kodlarının kullanılması, OEM tarafından genel hatalar döndürüldüğünde RIL hata ayıklamasını hızlandırabilir; çünkü GENERIC_FAILURE hata kodunun kesin nedenini belirlemek genellikle çok fazla zaman alabilir (ve bazen bunu anlamak imkansızdır).

Ek olarak, ril.h , RIL_LastCallFailCause ve RIL_DataCallFailCause numaralandırmaları için daha fazla hata kodu ekler; böylece satıcı kodu, CALL_FAIL_ERROR_UNSPECIFIED ve PDP_FAIL_ERROR_UNSPECIFIED gibi genel hataların döndürülmesini önleyebilir.

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

GENERIC_FAILURE kodunu değiştirmek için 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şturmanın uygulanması

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ı belirsizdi (bazı satıcıların yanlış bir sürüm bildirmesine neden oluyordu) ve sürümü tahmin etmeye yönelik geçici çözüm hatalı olmaya meyilliydi.

Android 7.x ve üzeri sürümlerde, ril.h tüm RIL sürüm değerlerini belgeler, karşılık gelen RIL sürümünü açıklar ve bu sürüme ilişkin tüm değişiklikleri listeler. Bir RIL sürümüne karşılık gelen değişiklikler yaparken satıcılar koddaki sürümlerini güncellemeli ve bu sürümü RIL_REGISTER döndürmelidir.

Gelişmiş RIL sürümünün doğrulanması

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

Wakelock'ları kullanarak RIL iletişimini uygulama

Zamanlanmış uyandırma kilitleri RIL iletişiminde belirsiz bir şekilde kullanılır ve bu da pil performansını olumsuz etkiler. Android 7.x ve sonraki sürümlerde, RIL isteklerini sınıflandırarak ve farklı istek türleri için uyanık kalma kilitlerini farklı şekilde işleyecek kodu güncelleyerek performansı artırabilirsiniz.

RIL isteklerini sınıflandırma

RIL talepleri talepli veya talepsiz olabilir. Satıcılar, talep edilen talepleri aşağıdakilerden biri olarak ayrıca sınıflandırmalıdır:

senkronize . Yanıtlanması önemli ölçüde zaman almayan istekler. Örneğin, RIL_REQUEST_GET_SIM_STATUS .
asenkron . Yanıtlanması oldukça zaman alan istekler. Örneğin, RIL_REQUEST_QUERY_AVAILABLE_NETWORKS .

Eşzamansız istenen RIL istekleri önemli ölçüde zaman alabilir. Satıcı kodundan bir onay aldıktan sonra RIL Java, uygulama işlemcisinin boşta kalma durumundan askıya alma durumuna geçmesine neden olabilecek uyanma kilidini serbest bırakır. Yanıt satıcı kodundan alındığında, RIL Java (uygulama işlemcisi) uyanık kalma kilidini yeniden alır, yanıtı işler ve ardından boşta döner. Rölantiden askıya alma ve rölantiye geçiş, çok fazla güç tüketebilir.

Yanıt süresi yeterince uzun değilse, uyanık kalma kilidini tutmak ve yanıt vermek için gereken tüm süre boyunca boşta kalmak, uyandırma kilidini serbest bırakarak ve yanıt geldiğinde uyanarak askıya alma durumuna geçmekten daha fazla güç verimliliği sağlayabilir. Satıcılar, tüm T süresi boyunca boşta kalarak tüketilen güç, aynı T süresi içinde boşta kalma durumundan beklemeye ve boşta kalma T geçerken tüketilen güçten daha büyük olduğunda, T süresinin eşik değerini belirlemek için platforma özgü güç ölçümlerini kullanmalıdır. T süresi bilindiğinde, T süresinden daha uzun süren RIL komutları asenkron olarak sınıflandırılabilir ve geri kalan komutlar senkron olarak sınıflandırılabilir.

RIL iletişim senaryoları

Aşağıdaki diyagramlar ortak RIL iletişim senaryolarını göstermekte ve RIL tarafından talep edilen ve edilmeyen istekleri işlemek üzere kodun değiştirilmesine yönelik çözümler sunmaktadır.

Not: Aşağıdaki diyagramlarda kullanılan işlevlere ilişkin uygulama ayrıntıları için ril.cpp dosyasındaki acquireWakeLock() , decrementWakeLock() ve clearWakeLock( ) yöntemlerine bakın.

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

Bu senaryoda, eğer RIL tarafından talep edilen yanıtın önemli ölçüde zaman alması bekleniyorsa (yani, RIL_REQUEST_GET_AVAILABLE_NETWORKS yanıtına bir yanıt), uyanık kalma kilidi uygulama işlemcisi tarafında uzun süre tutulur. Modem sorunları da uzun süre beklemeye neden olabilir.

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

Çözüm 1: Modem, RIL isteği ve eşzamansız yanıt için uyandırma kilidini tutar.

Şekil 2. Modem tarafından tutulan uyandırma kilidi.

RIL isteği gönderilir ve modem bu isteği işlemek için uyandırma kilidini alır.
Modem, Java tarafının uyandırma kilidi sayacını azaltmasına ve sayaç değeri 0 olduğunda serbest bırakmasına neden olan bir bildirim gönderir.
Not: Onayın oldukça hızlı bir şekilde alınması gerektiğinden, istek onayı dizisi için uyanma kilidi zaman aşımı süresi, halihazırda kullanılan zaman aşımı süresinden daha küçük olacaktır.
İsteği işledikten sonra modem, uyanık kalma kilidini alan satıcı koduna bir kesme gönderir ve ril.cpp'ye bir yanıt gönderir; o da uyandırma kilidini alır ve Java tarafına bir yanıt gönderir.
Yanıt Java tarafına ulaştığında uyandırma kilidi alınır ve arayan kişiye bir yanıt döndürülür.
Yanıt tüm modüller tarafından işlendikten sonra, onay (soket yoluyla) ril.cpp geri gönderilir ve bu daha sonra 3. adımda elde edilen uyanık kalma kilidini serbest bırakır.

Çözüm 2: Modem uyandırma kilidini tutmaz ve yanıt hızlıdır (senkron RIL isteği ve yanıtı). Senkronize ve asenkron davranış, belirli bir RIL komutu için sabit kodlanmıştır ve her çağrı temelinde kararlaştırılır.

Şekil 3. Uyandırma kilidi modem tarafından tutulmuyor.

RIL isteği, Java tarafında acquireWakeLock() çağrılarak gönderilir.
Satıcı kodunun uyandırma kilidi edinmesine gerek yoktur ve isteği işleyip hızlı bir şekilde yanıt verebilir.
Yanıt Java tarafından alındığında, uyanık kalma sayacını azaltan ve sayaç değeri 0 ise uyanıklığı serbest bırakan decrementWakeLock() çağrılır.

Senaryo: RIL istenmeyen yanıtı

Bu senaryoda, RIL istenmeyen yanıtlarında, satıcı yanıtı için bir uyandırma kilidinin edinilmesi gerekip gerekmediğini belirten bir uyandırma kilidi türü bayrağı bulunur. Bayrak ayarlandıysa, zamanlanmış bir uyandırma kilidi ayarlanır ve yanıt bir yuva üzerinden Java tarafına gönderilir. Zamanlayıcının 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.

Şekil 4. RIL istenmeyen yanıtı.

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

Şekil 5. Zamanlanmış uyandırma kilidi yerine ack'in kullanılması.

Yeniden tasarlanan uyandırma kilitleri doğrulanıyor

RIL çağrılarının eşzamanlı veya eşzamansız olarak tanımlandığını doğrulayın. Pil gücü tüketimi donanıma/platforma bağlı olabileceğinden, satıcıların, eşzamansız çağrılar için yeni uyandırma kilidi semantiğinin kullanılmasının pil gücü tasarrufuna yol açıp açmadığını öğrenmek için bazı dahili testler yapması gerekir.