Android 10 ngừng sử dụng dữ liệu múi giờ dựa trên APK cơ chế cập nhật (có trong Android 8.1 và Android 9) và thay thế bằng cơ chế này bằng cơ chế cập nhật mô-đun dựa trên APEX. AOSP 8.1 đến 13 vẫn bao gồm mã nền tảng cần thiết để OEM bật Các bản cập nhật dựa trên APK, giúp các thiết bị nâng cấp lên Android 10 vẫn có thể nhận thông tin cập nhật về dữ liệu múi giờ do đối tác cung cấp thông qua APK. Tuy nhiên, không nên sử dụng cơ chế cập nhật APK trên thiết bị chính thức nhận được các bản cập nhật mô-đun dưới dạng bản cập nhật dựa trên APK thay thế Bản cập nhật dựa trên APEX (tức là thiết bị nhận được bản cập nhật APK sẽ bỏ qua cập nhật dựa trên APEX).
Nội dung cập nhật về múi giờ (Android 10 trở lên)
Mô-đun Dữ liệu múi giờ được hỗ trợ trên Android 10 và cập nhật cao hơn về giờ mùa hè (DST) và múi giờ trên thiết bị Android, chuẩn hoá dữ liệu có thể thay đổi thường xuyên về tôn giáo, chính trị và lý do về địa chính trị.
Các bản cập nhật sử dụng quy trình sau:
- IANA phát hành một bản cập nhật cho Cơ sở dữ liệu múi giờ sẽ phát hành một bản cập nhật để phản hồi một hoặc nhiều chính phủ thay đổi quy tắc múi giờ ở quốc gia của họ.
- Google hoặc đối tác Android chuẩn bị cập nhật mô-đun Dữ liệu múi giờ (tệp APEX) chứa các múi giờ đã cập nhật.
- Thiết bị của người dùng cuối sẽ tải bản cập nhật xuống, khởi động lại, sau đó áp dụng thay đổi, sau đó dữ liệu múi giờ của thiết bị sẽ chứa múi giờ mới dữ liệu của bản cập nhật.
Để biết thông tin chi tiết về các mô-đun, hãy xem Thành phần hệ thống mô-đun.
Cập nhật múi giờ (Android 8.1–9)
Lưu ý: Tính năng cơ chế cập nhật dữ liệu múi giờ dựa trên APK đã đã bị xoá hoàn toàn khỏi Android 14 trở đi và không thể tìm thấy trong mã nguồn. Đối tác phải chuyển hoàn toàn sang Múi giờ Mô-đun Mainline.
Trong Android 8.1 và Android 9, OEM có thể sử dụng cơ chế dựa trên APK để đẩy đã cập nhật dữ liệu quy tắc múi giờ cho thiết bị mà không yêu cầu cập nhật hệ thống. Cơ chế này cho phép người dùng nhận được nội dung cập nhật kịp thời (từ đó mở rộng vòng đời hữu ích của thiết bị Android), đồng thời cho phép các đối tác Android thử nghiệm múi giờ cập nhật độc lập với bản cập nhật hình ảnh hệ thống.
Nhóm thư viện cốt lõi Android cung cấp các tệp dữ liệu cần thiết để đang cập nhật quy tắc múi giờ trên một thiết bị Android còn hàng. OEM có thể chọn sử dụng khi tạo cập nhật múi giờ cho thiết bị của họ hoặc có thể tạo tệp dữ liệu riêng nếu muốn. Trong mọi trường hợp, OEM (Nhà sản xuất thiết bị gốc) nắm quyền kiểm soát chất lượng đảm bảo/kiểm thử, định thời gian và triển khai việc cập nhật quy tắc múi giờ cho thiết bị được hỗ trợ.
Dữ liệu và mã nguồn múi giờ Android
Tất cả thiết bị Android có sẵn, ngay cả những thiết bị không dùng tính năng này, đều cần múi giờ
và phải gửi cùng với bộ dữ liệu quy tắc múi giờ mặc định trong
Phân vùng /system. Sau đó, mã từ
các thư viện sau đây trong cây nguồn Android:
- Mã do
libcore/quản lý (ví dụ:java.util.TimeZone) sử dụngtzdatavàtzlookup.xmltệp. - Mã thư viện gốc trong
bionic/(ví dụ:mktime(lệnh gọi hệ thống theo giờ địa phương) sử dụng tệptzdata. - Mã thư viện ICU4J/ICU4C trong
external/icu/sử dụng icu.dat.
Các thư viện này theo dõi các tệp lớp phủ có thể xuất hiện trong
Thư mục /data/misc/zoneinfo/current. Cần có tệp lớp phủ
chứa dữ liệu quy tắc múi giờ được cải thiện, từ đó cho phép cập nhật thiết bị
mà không thay đổi /system.
Các thành phần hệ thống Android cần dữ liệu về quy tắc múi giờ, hãy kiểm tra các mục sau vị trí lên đầu tiên:
- Mã
libcore/vàbionic/sử dụng Bản sao/datacủatzdatavàtzlookup.xmltệp. - Mã ICU4J/ICU4C sử dụng các tệp trong
/datavà quay lại sử dụng/systemtệp cho dữ liệu không xuất hiện (đối với các định dạng, đã bản địa hoá chuỗi, v.v.).
Tệp phân phối
Các tệp .zip phân phối chứa các tệp dữ liệu cần thiết để điền
Thư mục /data/misc/zoneinfo/current. Các tệp phân phối cũng
chứa siêu dữ liệu cho phép thiết bị phát hiện vấn đề liên quan đến phiên bản.
Định dạng tệp phân phối phụ thuộc vào bản phát hành Android vì nội dung thay đổi theo phiên bản ICU, yêu cầu nền tảng Android và bản phát hành khác thay đổi. Android cung cấp các tệp phân phối cho các bản phát hành Android được hỗ trợ cho mỗi Cập nhật IANA (ngoài việc cập nhật các tệp hệ thống của nền tảng). Để giữ chân thiết bị được cập nhật, OEM có thể sử dụng các tệp phân phối này hoặc tạo tệp của riêng họ bằng cây nguồn Android (chứa các tập lệnh và các tệp khác cần để tạo tệp phân phối).
Thành phần cập nhật múi giờ
Quá trình cập nhật quy tắc múi giờ liên quan đến việc truyền các tệp phân phối đến một thiết bị của bạn và cài đặt an toàn các tệp có trong đó. Chuyển và quá trình cài đặt yêu cầu:
- Chức năng dịch vụ của nền tảng
(
timezone.RulesManagerService), bị tắt theo mặc định. OEM phải bật chức năng này thông qua cấu hình.RulesManagerServicechạy trong quy trình và các giai đoạn của máy chủ hệ thống hoạt động cập nhật múi giờ bằng cách ghi vào/data/misc/zoneinfo/staged.RulesManagerServicecó thể đồng thời thay thế hoặc xoá các thao tác đã từng giai đoạn. -
TimeZoneUpdater! ứng dụng hệ thống không thể cập nhật (còn gọi là ứng dụng Trình cập nhật). OEM phải thêm ứng dụng này vào hình ảnh hệ thống thiết bị sử dụng tính năng này. - OEM
TimeZoneData! ứng dụng hệ thống có thể cập nhật (còn gọi là Ứng dụng dữ liệu) chứa các tệp phân phối đến thiết bị và tạo các tệp đó có sẵn cho ứng dụng Trình cập nhật. OEM phải đưa ứng dụng này vào hình ảnh hệ thống của các thiết bị sử dụng tính năng này. -
tzdatacheck! cần có tệp nhị phân thời gian khởi động để cập nhật múi giờ hoạt động chính xác và an toàn.
Cây nguồn Android chứa mã nguồn chung cho các mục trên các thành phần mà OEM có thể chọn sử dụng mà không cần sửa đổi. Mã kiểm thử được cung cấp để cho phép OEM tự động kiểm tra rằng họ đã bật tính năng này đúng cách.
Lắp đặt phân phối
Quy trình cài đặt bản phân phối bao gồm các bước sau:
- Ứng dụng dữ liệu được cập nhật thông qua việc tải xuống từ cửa hàng ứng dụng hoặc
tải từ nguồn không qua cửa hàng ứng dụng. Quá trình máy chủ hệ thống (thông qua
timezone.RulesManagerServer/timezone.PackageTrackerlớp) theo dõi các thay đổi đối với gói ứng dụng Dữ liệu đã được định cấu hình dành riêng cho OEM .
Hình 1. Cập nhật ứng dụng dữ liệu.
- Quy trình máy chủ hệ thống kích hoạt quá trình kiểm tra bản cập nhật bằng cách
truyền phát một ý định được nhắm mục tiêu bằng một mã thông báo dùng một lần duy nhất đến Trình cập nhật
Ứng dụng. Máy chủ hệ thống theo dõi mã thông báo gần đây nhất mà máy chủ tạo ra để mã này
có thể xác định thời điểm hoàn tất lần kiểm tra gần đây nhất mà hệ thống kích hoạt; bất kỳ loại nào khác
thì các mã thông báo này sẽ bị bỏ qua.
Hình 2. Kích hoạt kiểm tra bản cập nhật.
- Trong quá trình kiểm tra bản cập nhật, ứng dụng Trình cập nhật sẽ thực hiện
các nhiệm vụ sau:
- Truy vấn trạng thái hiện tại của thiết bị bằng cách gọi RulesManagerService.
Hình 3. Cập nhật ứng dụng dữ liệu, gọi RulesManagerService.
- Truy vấn ứng dụng Dữ liệu bằng cách truy vấn một URL ContentProvider được xác định rõ và
thông số cột để nhận thông tin về bản phân phối.
Hình 4. Cập nhật ứng dụng dữ liệu, nhận thông tin về bản phân phối.
- Truy vấn trạng thái hiện tại của thiết bị bằng cách gọi RulesManagerService.
- Ứng dụng Trình cập nhật thực hiện hành động phù hợp dựa trên
thông tin mà nó có. Các thao tác có thể thực hiện bao gồm:
- Yêu cầu cài đặt. Dữ liệu phân phối được đọc từ ứng dụng Dữ liệu và được chuyển đến RulesManagerService trong máy chủ hệ thống. Chiến lược phát hành đĩa đơn RulesManagerService xác nhận lại rằng phiên bản định dạng phân phối và nội dung phù hợp với thiết bị và giai đoạn cài đặt.
- Yêu cầu gỡ cài đặt (trường hợp này hiếm khi xảy ra). Ví dụ: nếu giá trị của thuộc tính
APK trong
/datađang bị tắt hoặc gỡ cài đặt và thiết bị đang quay lại phiên bản có trong/system. - Không làm gì cả. Xảy ra khi bản phân phối của ứng dụng Dữ liệu bị phát hiện là không hợp lệ.
Hình 5. Đã kiểm tra xong.
- Khởi động lại và tzdatacheck. Khi thiết bị khởi động lần tiếp theo,
tệp nhị phân tzdatacheck thực thi mọi thao tác theo giai đoạn. Tệp nhị phân tzdatacheck có thể
thực hiện các tác vụ sau:
- Thực thi thao tác theo giai đoạn bằng cách xử lý việc tạo, thay thế
và/hoặc xoá tệp
/data/misc/zoneinfo/currenttrước các thành phần hệ thống khác đã mở và bắt đầu sử dụng các tệp này. - Kiểm tra để đảm bảo các tệp trong
/datalà chính xác đối với tệp hiện tại phiên bản nền tảng. Tuy nhiên, điều này có thể không xảy ra nếu thiết bị vừa nhận được một bản cập nhật hệ thống và phiên bản định dạng phân phối đã thay đổi. - Đảm bảo rằng phiên bản quy tắc IANA giống hoặc mới hơn phiên bản trong
/system. Tính năng này giúp ngăn chặn một bản cập nhật hệ thống rời khỏi thiết bị có dữ liệu quy tắc múi giờ cũ hơn dữ liệu hiện có trong/systemhình ảnh.
- Thực thi thao tác theo giai đoạn bằng cách xử lý việc tạo, thay thế
và/hoặc xoá tệp
Độ tin cậy
Quá trình cài đặt hoàn chỉnh không đồng bộ và được chia thành ba hệ điều hành các quy trình. Tại bất kỳ thời điểm nào trong quá trình cài đặt, thiết bị có thể bị mất nguồn, chạy hết dung lượng ổ đĩa hoặc gặp các sự cố khác, khiến quá trình kiểm tra cài đặt chưa đầy đủ. Trong trường hợp không thành công tốt nhất, ứng dụng Trình cập nhật sẽ thông báo cho hệ thống máy chủ không thành công; trong trường hợp không thành công xấu nhất, RulesManagerService hoàn toàn không nhận được lệnh gọi nào.
Để xử lý vấn đề này, mã máy chủ hệ thống theo dõi xem liệu sự kiện đã hoàn tất quá trình kiểm tra bản cập nhật và mã phiên bản được kiểm tra gần đây nhất của Dữ liệu Ứng dụng. Khi thiết bị ở trạng thái rảnh và đang sạc, mã máy chủ hệ thống có thể kiểm tra trạng thái hiện tại. Nếu phát hiện thấy bước kiểm tra bản cập nhật chưa hoàn chỉnh hoặc Dữ liệu ngoài dự kiến Phiên bản ứng dụng sẽ tự động kích hoạt quá trình kiểm tra bản cập nhật.
Bảo mật
Khi được bật, mã RulesManagerService trong máy chủ hệ thống sẽ hoạt động một số bước kiểm tra để đảm bảo rằng hệ thống này an toàn để sử dụng.
- Sự cố cho biết hình ảnh hệ thống được định cấu hình không đúng sẽ ngăn thiết bị
khởi động; Ví dụ: Trình cập nhật/Cấu hình ứng dụng dữ liệu không hợp lệ hoặc
Trình cập nhật hoặc ứng dụng Dữ liệu không ở trong
/system/priv-app. - Các vấn đề cho biết một ứng dụng Dữ liệu không hợp lệ đã được cài đặt sẽ không ngăn chặn thiết bị khởi động nhưng ngăn kích hoạt quá trình kiểm tra bản cập nhật; ví dụ thiếu các quyền cần thiết trên hệ thống hoặc ứng dụng Dữ liệu không hiển thị ContentProvider trên URI dự kiến.
Các quyền đối với tệp đối với thư mục /data/misc/zoneinfo là
được thực thi bằng quy tắc SELinux. Giống như mọi APK khác, ứng dụng Dữ liệu phải được ký bằng
chính khoá dùng để ký phiên bản /system/priv-app. Ứng dụng Dữ liệu là
dự kiến sẽ có khoá và tên gói dành riêng cho OEM.
Tích hợp tính năng cập nhật múi giờ
Để bật tính năng cập nhật múi giờ, OEM thường:
- Tạo ứng dụng Dữ liệu của riêng mình.
- Đưa ứng dụng Trình cập nhật và ứng dụng Dữ liệu vào bản dựng hình ảnh hệ thống.
- Định cấu hình máy chủ hệ thống để bật RulesManagerService.
Chuẩn bị
Trước khi bắt đầu, OEM nên xem xét chính sách, quy trình đảm bảo chất lượng, và vấn đề bảo mật:
- Tạo khoá ký dành riêng cho ứng dụng cho ứng dụng Dữ liệu của họ.
- Tạo bản phát hành và chiến lược tạo phiên bản cho việc cập nhật múi giờ để biết thiết bị nào sẽ được cập nhật và cách họ có thể đảm bảo các bản cập nhật chỉ được cài đặt trên những thiết bị cần đến. Ví dụ: OEM (Nhà sản xuất thiết bị gốc) có thể muốn có một ứng dụng Dữ liệu duy nhất cho tất cả thiết bị của họ hoặc có thể chọn có Ứng dụng dữ liệu cho nhiều thiết bị. Quyết định này tác động đến việc lựa chọn gói tên, có thể là mã phiên bản được sử dụng và chiến lược đảm bảo chất lượng.
- Tìm hiểu xem họ có muốn sử dụng dữ liệu múi giờ Android sẵn có từ AOSP hoặc tự tạo.
Tạo một ứng dụng Dữ liệu
AOSP bao gồm tất cả mã nguồn và quy tắc bản dựng cần thiết để tạo một Ứng dụng dữ liệu trong
packages/apps/TimeZoneData, cùng với hướng dẫn và các mẫu ví dụ
cho AndroidManifest.xml và các tệp khác nằm trong
packages/apps/TimeZoneData/oem_template. Ví dụ về các mẫu bao gồm
cả mục tiêu bản dựng cho APK ứng dụng Dữ liệu thực và mục tiêu bổ sung cho
tạo các phiên bản thử nghiệm của ứng dụng Dữ liệu.
OEM có thể tuỳ chỉnh ứng dụng Dữ liệu bằng biểu tượng, tên, bản dịch và thông tin chi tiết khác. Tuy nhiên, vì không thể chạy ứng dụng Dữ liệu nên biểu tượng sẽ xuất hiện chỉ trong phần Cài đặt > Ứng dụng.
Ứng dụng Dữ liệu được xây dựng bằng bản dựng tapas tạo ra các APK phù hợp để thêm vào ảnh hệ thống (đối với phát hành) và được ký và phân phối thông qua một cửa hàng ứng dụng (để bản cập nhật). Để biết chi tiết về cách sử dụng món tapas, hãy xem phần Xây dựng Ứng dụng dữ liệu dùng món tapas.
OEM phải cài đặt ứng dụng Dữ liệu được tạo sẵn trong hình ảnh hệ thống của thiết bị trong
/system/priv-app. Để thêm các tệp APK tạo sẵn (do tapas tạo sẵn
quy trình xây dựng) trong hình ảnh hệ thống, OEM có thể sao chép tệp mẫu trong
packages/apps/TimeZoneData/oem_template/data_app_prebuilt. Chiến lược phát hành đĩa đơn
các mẫu ví dụ cũng bao gồm mục tiêu bản dựng để đưa vào các phiên bản thử nghiệm của
Ứng dụng dữ liệu trong bộ kiểm thử.
Thêm ứng dụng Trình cập nhật và ứng dụng Dữ liệu vào ảnh hệ thống
OEM phải đặt Trình cập nhật và APK ứng dụng dữ liệu trong
Thư mục /system/priv-app của hình ảnh hệ thống. Để làm được điều này,
bản dựng hình ảnh hệ thống phải bao gồm rõ ràng ứng dụng Trình cập nhật và ứng dụng Dữ liệu được tạo sẵn
mục tiêu.
Ứng dụng Trình cập nhật phải được ký bằng khoá nền tảng và đi kèm dưới dạng bất kỳ
ứng dụng hệ thống khác. Mục tiêu được xác định trong
packages/apps/TimeZoneUpdater theo phong cách TimeZoneUpdater. Chiến lược phát hành đĩa đơn
Việc đưa ứng dụng dữ liệu vào sẽ tuỳ thuộc vào OEM (Nhà sản xuất thiết bị gốc) cụ thể và phụ thuộc vào tên mục tiêu đã chọn cho
tạo sẵn.
Định cấu hình máy chủ hệ thống
Để bật tính năng cập nhật múi giờ, OEM có thể định cấu hình máy chủ hệ thống bằng cách
ghi đè thuộc tính cấu hình được xác định trong
frameworks/base/core/res/res/values/config.xml.
| Thuộc tính | Mô tả | Bắt buộc ghi đè? |
|---|---|---|
config_enableUpdateableTimeZoneRules |
Bạn phải đặt thành true để bật RulesManagerService. |
Có |
config_timeZoneRulesUpdateTrackingEnabled |
Bạn phải đặt thành true để hệ thống theo dõi các thay đổi đối với
ứng dụng Dữ liệu. |
Có |
config_timeZoneRulesDataPackage |
Tên gói của ứng dụng Dữ liệu dành riêng cho OEM. | Có |
config_timeZoneRulesUpdaterPackage |
Được định cấu hình cho ứng dụng Trình cập nhật mặc định. Chỉ thay đổi khi cung cấp cách triển khai ứng dụng Trình cập nhật khác. | Không |
config_timeZoneRulesCheckTimeMillisAllowed |
Thời gian cho phép giữa lần kiểm tra bản cập nhật được kích hoạt bởi RulesManagerService và phản hồi về lượt cài đặt, gỡ cài đặt hoặc không làm gì cả. Sau thì có thể tạo điều kiện kích hoạt độ tin cậy ngẫu nhiên. | Không |
config_timeZoneRulesCheckRetryCount |
Số lần kiểm tra cập nhật không thành công tuần tự được phép trước khi RulesManagerService ngừng tạo thêm. | Không |
Chế độ ghi đè cấu hình phải nằm trong hình ảnh hệ thống (không phải nhà cung cấp hay nhà cung cấp khác) vì thiết bị bị định cấu hình sai có thể từ chối khởi động. Nếu cấu hình ghi đè có trong hình ảnh nhà cung cấp, cập nhật lên hình ảnh hệ thống mà không cần ứng dụng Dữ liệu (hoặc có tên gói ứng dụng Trình cập nhật/ứng dụng dữ liệu khác nhau) sẽ được coi là cấu hình sai.
kiểm thử xTS
xTS là bộ kiểm thử dành riêng cho OEM (Nhà sản xuất thiết bị gốc) tương tự với Android tiêu chuẩn bộ kiểm thử sử dụng Tradefeed (chẳng hạn như CTS và VTS). OEM có bài kiểm tra như vậy bộ ứng dụng có thể thêm các thử nghiệm cập nhật múi giờ Android được cung cấp như sau vị trí:
packages/apps/TimeZoneData/testing/xtsbao gồm mã cần thiết cho việc kiểm thử chức năng tự động cơ bản.packages/apps/TimeZoneData/oem_template/xtscó chứa một mẫu cấu trúc thư mục để bao gồm các bài kiểm thử trong bộ xTS giống như Tradefeed. Giống như các thư mục mẫu khác, OEM dự kiến sẽ sao chép và tuỳ chỉnh theo của bạn.packages/apps/TimeZoneData/oem_template/data_app_prebuiltchứa cấu hình thời gian xây dựng để bao gồm APK kiểm thử được tạo sẵn cần thiết bằng cách kiểm thử.
Tạo nội dung cập nhật về múi giờ
Khi IANA phát hành một bộ quy tắc múi giờ mới, các thư viện cốt lõi của Android nhóm tạo bản vá để cập nhật bản phát hành trong AOSP. Nhà sản xuất thiết bị gốc sử dụng thiết bị Android có sẵn các tệp hệ thống và bản phân phối có thể nhận các thay đổi này, sử dụng chúng để tạo một phiên bản của ứng dụng Dữ liệu của họ, sau đó phát hành phiên bản mới để cập nhật thiết bị của họ trong giai đoạn phát hành chính thức.
Vì ứng dụng Dữ liệu chứa các tệp phân phối gắn liền với các phiên bản Android, Nhà sản xuất thiết bị gốc phải tạo phiên bản mới của ứng dụng Dữ liệu cho mọi ứng dụng được hỗ trợ Bản phát hành Android mà OEM muốn cập nhật. Ví dụ: nếu OEM (Nhà sản xuất thiết bị gốc) muốn cung cấp bản cập nhật cho Android 8.1, 9 và 10 thiết bị, họ phải hoàn tất quá trình ba lần.
Bước 1: Cập nhật hệ thống/múi giờ và các tệp dữ liệuicu/bên ngoài
Ở bước này, Nhà sản xuất thiết bị gốc sẽ xem xét các cam kết của Android đối với
system/timezone và external/icu từ
Các nhánh release-dev trong AOSP và áp dụng các thay đổi đó cho bản sao của chúng
mã nguồn Android.
Bản vá AOSP (Dự án nguồn mở Android) về hệ thống/múi giờ chứa các tệp đã cập nhật trong
system/timezone/input_data và
system/timezone/output_data. OEM (Nhà sản xuất thiết bị gốc) cần thực hiện thêm các phiên bản địa phương
bản sửa lỗi có thể sửa đổi tệp đầu vào, sau đó sử dụng các tệp trong
system/timezone/input_data và external/icu đến
tạo tệp trong output_data.
Tệp quan trọng nhất là
system/timezone/output_data/distro/distro.zip, tức là
tự động được đưa vào khi tạo APK ứng dụng dữ liệu.
Bước 2: Cập nhật mã phiên bản của ứng dụng Dữ liệu
Ở bước này, OEM cập nhật mã phiên bản của ứng dụng Dữ liệu. Bản dựng
tự động chọn distro.zip, nhưng phiên bản mới của
Ứng dụng dữ liệu phải có mã phiên bản mới để được nhận dạng là mới và dùng để
thay thế ứng dụng Dữ liệu được tải trước hoặc ứng dụng Dữ liệu được cài đặt trên một thiết bị bằng một ứng dụng trước đó
cập nhật.
Khi xây dựng ứng dụng Dữ liệu bằng các tệp được sao chép từ
package/apps/TimeZoneData/oem_template/data_app, bạn có thể tìm thấy
mã phiên bản/tên phiên bản áp dụng cho APK trong Android.mk:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
Bạn có thể tìm thấy các mục tương tự trong testing/Android.mk (tuy nhiên,
mã phiên bản thử nghiệm phải cao hơn phiên bản ảnh hệ thống). Để biết thông tin chi tiết,
hãy xem ví dụ về chiến lược mã phiên bản
lược đồ; nếu sử dụng lược đồ mẫu hoặc lược đồ tương tự, phép kiểm thử
không cần cập nhật mã phiên bản vì chúng được đảm bảo sẽ cao hơn
mã phiên bản thực.
Bước 3: Tạo lại, ký, kiểm thử và phát hành
Ở bước này, OEM (Nhà sản xuất thiết bị gốc) đã tạo lại APK bằng cách sử dụng tapas, ký APK, sau đó kiểm thử và phát hành APK:
- Đối với các thiết bị chưa phát hành (hoặc khi chuẩn bị bản cập nhật hệ thống cho một phát hành), hãy gửi APK mới trong thư mục tạo sẵn của ứng dụng Dữ liệu để đảm bảo rằng hình ảnh hệ thống và bài kiểm thử xTS có APK mới nhất. OEM nên kiểm tra xem tệp mới có hoạt động đúng cách không (tức là tệp vượt qua CTS và kiểm thử tự động và thủ công dành riêng cho OEM).
- Đối với các thiết bị đã phát hành không còn nhận được bản cập nhật hệ thống, tệp APK đã ký có thể chỉ được phát hành thông qua cửa hàng ứng dụng.
OEM chịu trách nhiệm đảm bảo chất lượng và thử nghiệm Ứng dụng dữ liệu trên thiết bị của họ trước khi phát hành.
Chiến lược mã phiên bản ứng dụng dữ liệu
Ứng dụng Dữ liệu phải có phù hợp tạo phiên bản để đảm bảo rằng thiết bị nhận được đúng tệp APK. Cho ví dụ: nếu nhận được một bản cập nhật hệ thống chứa APK cũ hơn một đã tải xuống từ cửa hàng ứng dụng, thì phiên bản cửa hàng ứng dụng sẽ được giữ lại.
Mã phiên bản APK phải bao gồm các thông tin sau:
- Phiên bản định dạng Distro (chính + phụ)
- Số phiên bản tăng dần (không rõ ràng)
Hiện tại, cấp API của nền tảng có mối tương quan chặt chẽ với phiên bản định dạng phân phối vì mỗi cấp độ API thường được liên kết với một phiên bản ICU mới ( làm cho các tệp phân phối không tương thích). Trong tương lai, Android có thể thay đổi điều này để mà một tệp phân phối có thể hoạt động trên nhiều bản phát hành nền tảng Android (và API) không được dùng trong lược đồ mã phiên bản ứng dụng dữ liệu).
Ví dụ về chiến lược mã phiên bản
Lược đồ số phiên bản trong ví dụ này đảm bảo rằng định dạng phân phối cao hơn
phiên bản thay thế phiên bản định dạng phân phối thấp hơn.
AndroidManifest.xml sử dụng android:minSdkVersion để
đảm bảo rằng thiết bị cũ không nhận được phiên bản có định dạng phân phối cao hơn
hơn mức chúng có thể xử lý.
Hình 6. Ví dụ về chiến lược mã phiên bản.
| Ví dụ | Giá trị | Mục đích |
|---|---|---|
| Có | Đặt trước | Cho phép các giao thức thay thế/APK kiểm thử trong tương lai. Ban đầu, đó là (ngầm ẩn) 0. Vì loại cơ bản là loại int 32 bit đã ký nên giao thức này hỗ trợ tối đa hai bản sửa đổi lược đồ đánh số trong tương lai. |
| 1 | Phiên bản định dạng lớn | Theo dõi phiên bản định dạng chính gồm 3 chữ số thập phân. Định dạng phân phối hỗ trợ 3 chữ số thập phân nhưng chỉ có 2 chữ số được sử dụng ở đây. Bạn khó có thể đạt được 100 dựa trên mức tăng chính dự kiến cho mỗi cấp độ API. Phiên bản lớn 1 là phiên bản tương đương lên API cấp 27. |
| 1 | Phiên bản định dạng nhỏ | Theo dõi phiên bản định dạng phụ gồm 3 chữ số thập phân. Định dạng phân phối hỗ trợ 3 chữ số thập phân nhưng chỉ có 1 chữ số được sử dụng ở đây. Cơ hội đó khó có thể đạt đến 10. |
| X | Đặt trước | Là 0 đối với bản phát hành công khai (và có thể khác đối với APK thử nghiệm). |
| Hàm ZZZZZ | Số phiên bản mờ | Số thập phân được phân bổ theo yêu cầu. Bao gồm các khoảng trống để cho phép quảng cáo xen kẽ cần cập nhật nếu cần. |
Lược đồ có thể được đóng gói tốt hơn nếu sử dụng tệp nhị phân thay vì số thập phân, nhưng lược đồ này có lợi thế là con người có thể đọc được. Nếu toàn bộ phạm vi số đã hết, thì tên gói ứng dụng Dữ liệu có thể thay đổi.
Tên phiên bản là cách thể hiện chi tiết mà con người có thể đọc được, vì
ví dụ: major=001,minor=001,iana=2017a, revision=1,respin=2.
Ví dụ được hiển thị trong bảng sau.
| # | Mã phiên bản | minSdkVersion | {Major format version},{Minor format version},{Quy tắc của IANA version},{Bản sửa đổi} |
|---|---|---|---|
| 1 | 11000010 | O-MR1 | lớn=001,minor=001,iana=2017a,bản sửa đổi=1 |
| 2 | 21000010 | Điểm | lớn=002,minor=001,iana=2017a,bản sửa đổi=1 |
| 3 | 11000020 | O-MR1 | lớn=001,minor=001,iana=2017a,bản sửa đổi=2 |
| 4 | 11000030 | O-MR1 | lớn=001,minor=001,iana=2017b,bản sửa đổi=1 |
| 5 | 21000020 | Điểm | lớn=002,minor=001,iana=2017b,bản sửa đổi=1 |
| 6 | 11000040 | O-MR1 | lớn=001,minor=001,iana=2018a,bản sửa đổi=1 |
| 7 | 21000030 | Điểm | lớn=002,minor=001,iana=2018a,bản sửa đổi=1 |
| 8 | 1123456789 | - | - |
| 9 | 11000021 | O-MR1 | lớn=001,minor=001,iana=2017a,sửa đổi=2,respin=2 |
- Ví dụ 1 và 2 hiển thị hai phiên bản APK cho cùng một bản phát hành IANA 2017a với các phiên bản định dạng chính khác nhau. 2 lớn hơn 1, tức là cần thiết để đảm bảo rằng các thiết bị mới nhận được phiên bản có định dạng cao hơn. Chiến lược phát hành đĩa đơn minSdkVersion đảm bảo rằng phiên bản P sẽ không được cung cấp cho các thiết bị O.
- Ví dụ 3 là bản sửa đổi/sửa chữa cho 1 và có số cao hơn 1.
- Ví dụ 4 và 5 cho thấy các bản phát hành năm 2017b của O-MR1 và P. Về mặt số lượng cao hơn, chúng thay thế các bản phát hành IANA/bản sửa đổi Android trước đây của các phiên bản những người tiền nhiệm.
- Ví dụ 6 và 7 cho thấy các bản phát hành năm 2018a của O-MR1 và P.
- Ví dụ 8 minh hoạ việc sử dụng Y để thay thế hoàn toàn giao thức Y=0.
- Ví dụ 9 minh hoạ việc sử dụng khoảng trống còn lại giữa 3 và 4 để xoay lại gói ứng dụng.
Vì mỗi thiết bị đều đi kèm với một APK mặc định, có phiên bản phù hợp trong
hình ảnh hệ thống, không có nguy cơ phiên bản O-MR1 được cài đặt trên thiết bị P
vì phiên bản này có số phiên bản thấp hơn phiên bản ảnh hệ thống P. Đáp
thiết bị có phiên bản O-MR1 được cài đặt trong /data mà sau đó nhận được
bản cập nhật hệ thống cho P sử dụng phiên bản /system được ưu tiên để
phiên bản O-MR1 trong /data vì phiên bản P luôn cao hơn
hơn bất kỳ ứng dụng nào dành cho O-MR1.
Tạo ứng dụng Dữ liệu bằng tapas
OEM chịu trách nhiệm quản lý hầu hết các khía cạnh của ứng dụng Dữ liệu múi giờ định cấu hình hình ảnh hệ thống chính xác. Ứng dụng Dữ liệu được xây dựng bằng một bản dựng tapas tạo ra các APK phù hợp để thêm vào hình ảnh hệ thống (cho bản phát hành đầu tiên) rồi ký và phân phối thông qua cửa hàng ứng dụng (cho các bản cập nhật tiếp theo).
Tapas là một phiên bản thu gọn của bản dựng Android trong đó sử dụng cây nguồn rút gọn để tạo ra các phiên bản có thể phân phối của của chúng tôi. OEM đã quen thuộc với hệ thống xây dựng Android thông thường phải nhận ra từ bản dựng nền tảng Android thông thường.
Tạo tệp kê khai
Thông thường, bạn sẽ sử dụng được cây nguồn rút gọn bằng một tệp kê khai tuỳ chỉnh
chỉ đề cập đến các dự án Git mà hệ thống xây dựng và để tạo
. Sau khi làm theo các hướng dẫn trong
Tạo ứng dụng dữ liệu, OEM nên có tại
ít nhất hai dự án Git dành riêng cho OEM được tạo bằng cách sử dụng các tệp mẫu trong
packages/apps/TimeZoneData/oem_template:
- Một dự án Git chứa các tệp ứng dụng như tệp kê khai và
tệp bản dựng cần thiết để tạo tệp APK ứng dụng (ví dụ:
vendor/oem/apps/TimeZoneData). Dự án này cũng chứa các quy tắc bản dựng cho tệp APK kiểm thử mà chương trình kiểm thử xTS có thể sử dụng. - Một dự án Git chứa các APK đã ký do bản dựng ứng dụng tạo ra cho đưa vào bản dựng hình ảnh hệ thống và kiểm thử xTS.
Bản dựng ứng dụng tận dụng một số dự án Git khác được chia sẻ với bản dựng nền tảng hoặc chứa các thư viện mã độc lập với OEM.
Đoạn mã tệp kê khai sau đây chứa tập hợp dự án Git tối thiểu cần để hỗ trợ bản dựng O-MR1 của ứng dụng Dữ liệu múi giờ. OEM (Nhà sản xuất thiết bị gốc) phải thêm dự án Git dành riêng cho OEM (thường bao gồm một dự án chứa chứng chỉ ký) vào tệp kê khai này và có thể định cấu hình các cấu hình khác nhau phân nhánh phù hợp.
<!-- Tapas Build -->
<project
path="build"
name="platform/build">
<copyfile src="core/root.mk" dest="Makefile" />
</project>
<project
path="prebuilts/build-tools"
name="platform/prebuilts/build-tools"
clone-depth="1" />
<project
path="prebuilts/go/linux-x86"
name="platform/prebuilts/go/linux-x86"
clone-depth="1" />
<project
path="build/blueprint"
name="platform/build/blueprint" />
<project
path="build/kati"
name="platform/build/kati" />
<project
path="build/soong"
name="platform/build/soong">
<linkfile src="root.bp" dest="Android.bp" />
<linkfile src="bootstrap.bash" dest="bootstrap.bash" />
</project>
<!-- SDK for system / public API stubs -->
<project
path="prebuilts/sdk"
name="platform/prebuilts/sdk"
clone-depth="1" />
<!-- App source -->
<project
path="system/timezone"
name="platform/system/timezone" />
<project
path="packages/apps/TimeZoneData"
name="platform/packages/apps/TimeZoneData" />
<!-- Enable repohooks -->
<project
path="tools/repohooks"
name="platform/tools/repohooks"
revision="main"
clone_depth="1" />
<repo-hooks
in-project="platform/tools/repohooks"
enabled-list="pre-upload" />
Chạy bản dựng tapas
Sau khi thiết lập cây nguồn, hãy gọi bản dựng tapas bằng các lệnh sau:
source build/envsetup.shtapasmake -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
Một bản dựng thành công sẽ tạo các tệp trong thư mục out/dist cho
kiểm thử. Bạn có thể đặt những tệp này vào thư mục tạo sẵn để đưa vào
hình ảnh hệ thống và/hoặc được phân phối thông qua cửa hàng ứng dụng để
thiết bị.