Android 7.0 đã tái cấu trúc Lớp giao diện vô tuyến (RIL) bằng một tập hợp các tính năng để cải thiện chức năng RIL. Bạn cần thay đổi mã đối tác để triển khai các tính năng này. Các tính năng này là không bắt buộc nhưng bạn nên triển khai. Các thay đổi về tái cấu trúc tương thích ngược, vì vậy, các cách triển khai trước đó của các tính năng được tái cấu trúc vẫn hoạt động.
Việc tái cấu trúc RIL bao gồm những điểm cải tiến sau:
- Mã lỗi RIL. Cho phép sử dụng các mã lỗi cụ thể ngoài mã
GENERIC_FAILUREhiện có. Điều này hỗ trợ khắc phục sự cố bằng cách cung cấp thông tin cụ thể hơn về nguyên nhân gây ra lỗi. - Tạo phiên bản RIL. Cung cấp thông tin phiên bản chính xác hơn và dễ định cấu hình hơn.
- Giao tiếp RIL bằng cách sử dụng wakelock. Cải thiện hiệu suất pin của thiết bị.
Bạn có thể triển khai bất kỳ hoặc tất cả các điểm cải tiến nêu trên. Để biết thêm thông tin chi tiết,
hãy tham khảo ý kiến về mã về việc tạo phiên bản RIL trong
https://android.googlesource.com/platform/hardware/ril/+/android17-release/include/telephony/ril.h.
Triển khai mã lỗi RIL nâng cao
Hầu hết các lệnh gọi yêu cầu RIL đều có thể trả về mã lỗi GENERIC_FAILURE để phản hồi lỗi. Đây là vấn đề với tất cả các phản hồi được yêu cầu do OEM trả về. Điều này có thể khiến bạn khó gỡ lỗi một vấn đề trong báo cáo lỗi nếu lệnh gọi RIL trả về cùng một mã lỗi GENERIC_FAILURE vì nhiều lý do. Các nhà cung cấp có thể mất nhiều thời gian để xác định phần mã nào có thể trả về mã GENERIC_FAILURE.
Trong Android 7.x trở lên, OEM có thể trả về một giá trị mã lỗi riêng biệt liên kết với từng lỗi khác nhau hiện được phân loại là GENERIC_FAILURE. Các OEM không muốn tiết lộ công khai mã lỗi tuỳ chỉnh của mình có thể trả về lỗi dưới dạng một tập hợp số nguyên riêng biệt (chẳng hạn như từ 1 đến x) được liên kết dưới dạng OEM_ERROR_1 đến OEM_ERROR_X. Các nhà cung cấp phải đảm bảo rằng mỗi mã lỗi được che giấu như vậy được trả về sẽ liên kết với một lý do lỗi riêng biệt trong mã. Việc sử dụng các mã lỗi cụ thể có thể giúp tăng tốc quá trình gỡ lỗi RIL bất cứ khi nào OEM trả về các lỗi chung, vì việc xác định chính xác nguyên nhân gây ra mã lỗi GENERIC_FAILURE thường mất quá nhiều thời gian (và đôi khi không thể xác định được).
Ngoài ra, ril.h sẽ thêm nhiều mã lỗi hơn cho các enum RIL_LastCallFailCause và RIL_DataCallFailCause để mã nhà cung cấp có thể tránh trả về các lỗi chung như CALL_FAIL_ERROR_UNSPECIFIED và PDP_FAIL_ERROR_UNSPECIFIED.
Xác thực mã lỗi RIL nâng cao
Sau khi thêm mã lỗi mới để thay thế mã GENERIC_FAILURE, hãy xác minh rằng lệnh gọi RIL trả về mã lỗi mới thay vì GENERIC_FAILURE.
Triển khai tính năng tạo phiên bản RIL nâng cao
Việc tạo phiên bản RIL trong các bản phát hành Android cũ gặp vấn đề: phiên bản này không chính xác, cơ chế báo cáo phiên bản RIL không rõ ràng (khiến một số nhà cung cấp báo cáo phiên bản không chính xác) và giải pháp ước tính phiên bản dễ bị không chính xác.
Trong Android 7.x trở lên, ril.h sẽ ghi lại tất cả các giá trị phiên bản RIL, mô tả phiên bản RIL tương ứng và liệt kê tất cả các thay đổi cho phiên bản đó. Khi thực hiện các thay đổi tương ứng với phiên bản RIL, các nhà cung cấp phải cập nhật phiên bản của họ trong mã và trả về phiên bản đó trong RIL_REGISTER.
Xác thực tính năng tạo phiên bản RIL nâng cao
Xác minh rằng phiên bản RIL tương ứng với mã RIL của bạn được trả về trong RIL_REGISTER (thay vì RIL_VERSION được xác định trong ril.h).
Triển khai giao tiếp RIL bằng cách sử dụng wakelock
Wakelock theo thời gian được sử dụng trong giao tiếp RIL theo cách không chính xác, điều này ảnh hưởng tiêu cực đến hiệu suất pin. Trong Android 7.x trở lên, bạn có thể cải thiện hiệu suất bằng cách phân loại các yêu cầu RIL và cập nhật mã để xử lý wakelock theo cách khác cho các loại yêu cầu khác nhau.
Phân loại yêu cầu RIL
Yêu cầu RIL có thể là yêu cầu được yêu cầu hoặc không được yêu cầu. Các nhà cung cấp nên phân loại thêm các yêu cầu được yêu cầu là một trong những yêu cầu sau:
- đồng bộ. Các yêu cầu không mất nhiều thời gian để phản hồi. Ví dụ:
RIL_REQUEST_GET_SIM_STATUS. - không đồng bộ. Các yêu cầu mất nhiều thời gian để phản hồi. Ví dụ:
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.
Các yêu cầu RIL được yêu cầu không đồng bộ có thể mất nhiều thời gian. Sau khi nhận được thông báo xác nhận từ mã nhà cung cấp, RIL Java sẽ phát hành wakelock. Điều này có thể khiến bộ xử lý ứng dụng chuyển từ trạng thái rảnh sang trạng thái tạm ngưng. Khi phản hồi có sẵn từ mã nhà cung cấp, RIL Java (bộ xử lý ứng dụng) sẽ lấy lại wakelock, xử lý phản hồi, sau đó quay lại trạng thái rảnh. Việc chuyển từ trạng thái rảnh sang trạng thái tạm ngưng rồi quay lại trạng thái rảnh có thể tiêu tốn nhiều năng lượng.
Nếu thời gian phản hồi không đủ dài, việc giữ wakelock và ở trạng thái rảnh trong toàn bộ thời gian phản hồi có thể tiết kiệm năng lượng hơn so với việc chuyển sang trạng thái tạm ngưng bằng cách phát hành wakelock và đánh thức khi phản hồi đến. Các nhà cung cấp nên sử dụng các phép đo năng lượng dành riêng cho nền tảng để xác định giá trị ngưỡng của thời gian T khi năng lượng tiêu thụ khi ở trạng thái rảnh trong toàn bộ thời gian T lớn hơn năng lượng tiêu thụ khi chuyển từ trạng thái rảnh sang trạng thái tạm ngưng và quay lại trạng thái rảnh trong cùng thời gian T. Khi biết thời gian T, các lệnh RIL mất nhiều thời gian hơn thời gian T có thể được phân loại là không đồng bộ và các lệnh còn lại được phân loại là đồng bộ.
Các tình huống giao tiếp RIL
Các sơ đồ sau đây minh hoạ các tình huống giao tiếp RIL phổ biến và cung cấp giải pháp để sửa đổi mã nhằm xử lý các yêu cầu RIL được yêu cầu và không được yêu cầu.
Lưu ý: Để biết thông tin chi tiết về cách triển khai các hàm được sử dụng trong các sơ đồ sau đây, hãy tham khảo các phương thức acquireWakeLock(), decrementWakeLock() và clearWakeLock() trong ril.cpp.
Tình huống: Yêu cầu RIL và phản hồi không đồng bộ được yêu cầu
Trong tình huống này, nếu phản hồi được yêu cầu RIL dự kiến sẽ mất nhiều thời gian (tức là phản hồi cho RIL_REQUEST_GET_AVAILABLE_NETWORKS), thì wakelock sẽ được giữ trong một thời gian dài ở phía bộ xử lý ứng dụng. Các vấn đề về modem cũng có thể dẫn đến thời gian chờ lâu.
Giải pháp 1: Modem giữ wakelock cho yêu cầu RIL và phản hồi không đồng bộ.
- Yêu cầu RIL được gửi và modem lấy wakelock để xử lý yêu cầu đó.
- Modem gửi thông báo xác nhận khiến phía Java giảm bộ đếm wakelock và phát hành khi giá trị bộ đếm là 0.
Lưu ý: Thời gian chờ wakelock cho chuỗi yêu cầu-xác nhận sẽ nhỏ hơn thời gian chờ hiện được sử dụng vì thông báo xác nhận sẽ được nhận khá nhanh.
- Sau khi xử lý yêu cầu, modem sẽ gửi một lệnh gián đoạn đến mã nhà cung cấp lấy wakelock và gửi phản hồi đến ril.cpp. Mã này sẽ lấy wakelock và gửi phản hồi đến phía Java.
- Khi phản hồi đến phía Java, wakelock sẽ được lấy và phản hồi sẽ được trả về cho người gọi.
- Sau khi tất cả các mô-đun xử lý phản hồi, thông báo xác nhận sẽ được gửi (qua socket) trở lại
ril.cpp. Sau đó, mã này sẽ phát hành wakelock được lấy ở bước 3.
Giải pháp 2: Modem không giữ wakelock và phản hồi nhanh (yêu cầu và phản hồi RIL đồng bộ). Hành vi đồng bộ so với không đồng bộ được mã hoá cứng cho một lệnh RIL cụ thể và được quyết định dựa trên cơ sở từng lệnh gọi.
- Yêu cầu RIL được gửi bằng cách gọi
acquireWakeLock()ở phía Java. - Mã nhà cung cấp không cần lấy wakelock và có thể xử lý yêu cầu và phản hồi nhanh chóng.
- Khi phản hồi được phía Java nhận,
decrementWakeLock()sẽ được gọi. Phương thức này sẽ giảm bộ đếm wakelock và phát hành wakelock nếu giá trị bộ đếm là 0.
Tình huống: Phản hồi không mong muốn RIL
Trong tình huống này, các phản hồi không được yêu cầu RIL có một cờ loại wakelock trong đó cho biết có cần lấy wakelock cho phản hồi của nhà cung cấp hay không. Nếu cờ được đặt, wakelock theo thời gian sẽ được đặt và phản hồi sẽ được gửi qua socket đến phía Java. Khi bộ hẹn giờ hết hạn, wakelock sẽ được phát hành. Wakelock theo thời gian có thể quá dài hoặc quá ngắn đối với các phản hồi không được yêu cầu RIL khác nhau.
Giải pháp: Thông báo xác nhận được gửi từ mã Java đến phía gốc (ril.cpp) thay vì giữ wakelock theo thời gian ở phía gốc trong khi gửi phản hồi không được yêu cầu.
Xác thực wakelock được thiết kế lại
Xác minh rằng các lệnh gọi RIL được xác định là đồng bộ hoặc không đồng bộ. Vì mức tiêu thụ pin có thể phụ thuộc vào phần cứng/nền tảng, nên các nhà cung cấp cần thực hiện một số thử nghiệm nội bộ để tìm hiểu xem việc sử dụng ngữ nghĩa wakelock mới cho các lệnh gọi không đồng bộ có giúp tiết kiệm pin hay không.