Quy tắc về múi giờ

Android 10 ngừng sử dụng cơ chế cập nhật dữ liệu múi giờ dựa trên APK (có trong Android 8.1 và Android 9) và thay thế 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 để các OEM bật tính năng cập nhật dựa trên APK, vì vậy, các thiết bị nâng cấp lên Android 10 vẫn có thể nhận được bản cập nhật dữ liệu múi giờ do đối tác cung cấp thông qua APK. Tuy nhiên, bạn không nên sử dụng cơ chế cập nhật APK trên một thiết bị phát hành cũng đang nhận các bản cập nhật mô-đun vì bản cập nhật dựa trên APK sẽ 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ác bản cập nhật dựa trên APEX).

Bản cập nhật múi giờ (Android 10 trở lên)

Mô-đun Dữ liệu múi giờ được hỗ trợ trong Android 10 trở lên sẽ cập nhật giờ tiết kiệm ánh sáng ban ngày (DST) và múi giờ trên các thiết bị Android, chuẩn hoá dữ liệu có thể thay đổi thường xuyên vì lý do tôn giáo, chính trị và địa chính trị.

Các bản cập nhật sử dụng quy trình sau:

1. IANA phát hành bản cập nhật cho Cơ sở dữ liệu múi giờ để phản hồi việc một hoặc nhiều chính phủ thay đổi quy tắc múi giờ ở quốc gia của họ.
2. Google hoặc đối tác Android chuẩn bị một bản cập nhật mô-đun Dữ liệu múi giờ (tệp APEX) chứa các múi giờ mới cập nhật.
3. 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 các thay đổi. Sau đó, dữ liệu múi giờ của thiết bị sẽ chứa dữ liệu múi giờ mới trong bản cập nhật.

Để biết thông tin chi tiết về các mô-đun, hãy xem phần Thành phần hệ thống mô-đun.

Bản 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ở lên và không có trong mã nguồn. Đối tác nên di chuyển hoàn toàn sang mô-đun Dòng chính múi giờ.

Trong Android 8.1 và Android 9, các OEM có thể sử dụng cơ chế dựa trên APK để truyền dữ liệu quy tắc múi giờ đã cập nhật đến các thiết bị mà không cần phải cập nhật hệ thống. Cơ chế này giúp người dùng nhận được các bản cập nhật kịp thời (nhờ đó kéo dài thời gian sử dụng hữu ích của thiết bị Android) và giúp các đối tác của Android kiểm thử các bản cập nhật múi giờ độc lập với các 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 để cập nhật quy tắc múi giờ trên một thiết bị Android gốc. Các nhà sản xuất thiết bị gốc có thể chọn sử dụng các tệp dữ liệu này khi tạo bản 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 vẫn giữ quyền kiểm soát việc đảm bảo/kiểm thử chất lượng, thời gian và việc ra mắt các bản cập nhật quy tắc múi giờ cho các thiết bị được hỗ trợ.

Mã nguồn và dữ liệu múi giờ của Android

Tất cả các thiết bị Android gốc, ngay cả những thiết bị không sử dụng tính năng này, đều cần dữ liệu quy tắc múi giờ và phải đi kèm với một bộ dữ liệu quy tắc múi giờ mặc định trong phân vùng /system. Sau đó, dữ liệu này sẽ được mã từ các thư viện sau đây sử dụng trong cây nguồn Android:

• Mã được quản lý từ libcore/ (ví dụ: java.util.TimeZone) sử dụng các tệp tzdata và tzlookup.xml.
• Mã thư viện gốc trong bionic/ (ví dụ: đối với mktime, lệnh gọi hệ thống localtime) sử dụng tệp tzdata.
• Mã thư viện ICU4J/ICU4C trong external/icu/ sử dụng tệp icu .dat.

Các thư viện này theo dõi các tệp lớp phủ có thể có trong thư mục /data/misc/zoneinfo/current. Các tệp lớp phủ dự kiến sẽ chứa dữ liệu quy tắc múi giờ được cải thiện, nhờ đó cho phép thiết bị được cập nhật mà không cần thay đổi /system.

Các thành phần hệ thống Android cần dữ liệu quy tắc múi giờ sẽ kiểm tra các vị trí sau đây trước:

• Mã libcore/ và bionic/ sử dụng bản sao /data của các tệp tzdata và tzlookup.xml.
• Mã ICU4J/ICU4C sử dụng các tệp trong /data và quay lại các tệp /system cho dữ liệu không có (đối với định dạng, chuỗi được bản địa hoá, v.v.).

Tệp phân phối

Các tệp .zip của bản phân phối chứa các tệp dữ liệu cần thiết để điền vào 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 các vấn đề về 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, các yêu cầu của nền tảng Android và các thay đổi khác trong bản phát hành. 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 bản cập nhật IANA (ngoài việc cập nhật các tệp hệ thống nền tảng). Để duy trì thiết bị ở trạng thái mới nhất, OEM có thể sử dụng các tệp phân phối này hoặc tự tạo bằng cây nguồn Android (chứa các tập lệnh và tệp khác cần thiết để tạo tệp phân phối).

Các thành phần cập nhật múi giờ

Bản cập nhật quy tắc múi giờ liên quan đến việc truyền tệp phân phối đến một thiết bị và cài đặt an toàn các tệp có trong đó. Để chuyển và cài đặt, bạn cần có những thứ sau:

• Chức năng dịch vụ nền tảng (timezone.RulesManagerService), bị tắt theo mặc định. Các OEM phải bật chức năng này thông qua cấu hình. RulesManagerService chạy trong quy trình máy chủ hệ thống và dàn xếp các thao tác cập nhật múi giờ bằng cách ghi vào /data/misc/zoneinfo/staged. RulesManagerService cũng có thể thay thế hoặc xoá các thao tác đã được dàn dựng.
• TimeZoneUpdater, một ứng dụng hệ thống không cập nhật được (còn gọi là ứng dụng Trình cập nhật). Nhà sản xuất thiết bị gốc 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.
• OEM TimeZoneData, một ứng dụng hệ thống có thể cập nhật (còn gọi là Ứng dụng dữ liệu) truyền các tệp phân phối đến thiết bị và cung cấp các tệp đó cho ứng dụng Trình cập nhật. Các OEM phải đưa ứng dụng này vào hình ảnh hệ thống của những thiết bị sử dụng tính năng này.
• tzdatacheck, một tệp nhị phân khi khởi động cần thiết để hoạt động cập nhật múi giờ diễn ra chính xác và an toàn.

Cây nguồn Android chứa mã nguồn chung cho các thành phần nêu trên. OEM có thể chọn sử dụng mã nguồn này mà không cần sửa đổi. Mã kiểm thử được cung cấp để giúp các OEM tự động kiểm tra xem họ đã bật tính năng này đúng cách hay chưa.

Cài đặt bản phân phối

Quy trình cài đặt bản phân phối bao gồm các bước sau:

1. Ứng dụng dữ liệu được cập nhật thông qua bản tải xuống từ cửa hàng ứng dụng hoặc tải lên từ bên ngoài. Quy trình máy chủ hệ thống (thông qua các lớp timezone.RulesManagerServer/timezone.PackageTracker) theo dõi các thay đổi đối với tên gói ứng dụng Dữ liệu dành riêng cho OEM đã định cấu hình.
   
   

   Hình 1. Bản cập nhật ứng dụng dữ liệu.

2. Quy trình máy chủ hệ thống kích hoạt một quy trình kiểm tra bản cập nhật bằng cách truyền một ý định nhắm đến mục tiêu cụ thể kèm theo một mã thông báo dùng một lần duy nhất cho Ứng dụng Trình cập nhật. Máy chủ hệ thống theo dõi mã thông báo gần đây nhất mà hệ thống đã tạo để có thể xác định thời điểm hoàn tất quy trình kiểm tra gần đây nhất mà hệ thống đã kích hoạt; mọi mã thông báo khác đều bị bỏ qua.
   
   

   Hình 2. Kích hoạt quy trình kiểm tra bản cập nhật.

3. 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 tác 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. Ứng dụng dữ liệu cập nhật, gọi RulesManagerService.

   • Truy vấn ứng dụng Dữ liệu bằng cách truy vấn URL ContentProvider và thông số cột được xác định rõ để lấy 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.

4. Ứng dụng Updater sẽ thực hiện hành động thích hợp dựa trên thông tin mà ứng dụng có. Các thao tác có thể thực hiện bao gồm:
   • Yêu cầu lắp đặt. Dữ liệu phân phối được đọc từ ứng dụng Dữ liệu và được truyền đến RulesManagerService trong máy chủ hệ thống. RulesManagerService xác nhận lại rằng phiên bản và nội dung định dạng phân phối phù hợp với thiết bị và chuẩn bị cho quá trình 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 APK đã cập nhật trong /data đang bị vô hiệu hoá hoặc gỡ cài đặt và thiết bị đang quay về phiên bản có trong /system.
   • Không làm gì cả. Xảy ra khi hệ thống phát hiện thấy bản phân phối ứng dụng Dữ liệu không hợp lệ.
   Trong mọi trường hợp, ứng dụng Trình cập nhật sẽ gọi RulesManagerService bằng mã thông báo kiểm tra để máy chủ hệ thống biết rằng quá trình kiểm tra đã hoàn tất và thành công.
   
   

   Hình 5. Đã kiểm tra xong.

5. 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 sẽ 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 thao tác 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á các tệp /data/misc/zoneinfo/current trước khi các thành phần khác của hệ thống mở và bắt đầu sử dụng các tệp này.
   • Kiểm tra để đảm bảo rằng các tệp trong /data phù hợp với phiên bản nền tảng hiện tại. Điều này có thể không đúng nếu thiết bị vừa nhận được 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 bằng hoặc mới hơn phiên bản trong /system. Điều này giúp ngăn chặn bản cập nhật hệ thống để lại cho thiết bị dữ liệu quy tắc múi giờ cũ hơn so với dữ liệu có trong hình ảnh /system.

Độ tin cậy

Quy trình cài đặt từ đầu đến cuối là không đồng bộ và được chia thành 3 quy trình hệ điều hành. Tại bất kỳ thời điểm nào trong quá trình cài đặt, thiết bị có thể mất nguồn, hết dung lượng ổ đĩa hoặc gặp phải các vấn đề khác, khiến quá trình kiểm tra cài đặt không hoàn tất. Trong trường hợp không thành công tốt nhất, ứng dụng Updater sẽ thông báo cho máy chủ hệ thống rằng ứng dụng không thành công; trong trường hợp không thành công tệ nhất, RulesManagerService sẽ không nhận được lệnh gọi nào.

Để xử lý việc này, mã máy chủ hệ thống sẽ theo dõi xem một quy trình kiểm tra bản cập nhật đã kích hoạt có hoàn tất hay không và mã phiên bản đã kiểm tra gần đây nhất của Ứng dụng dữ liệu là gì. Khi thiết bị ở trạng thái không hoạt động 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 quy trình kiểm tra bản cập nhật chưa hoàn tất hoặc phiên bản DataApp không mong muốn, thì ứng dụng sẽ tự động kích hoạt quy 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ẽ thực hiện một số bước kiểm tra để đảm bảo hệ thống an toàn khi sử dụng.

• Các vấn đề cho thấy 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ụ: cấu hình Updater hoặc Data app không đúng hoặc Updater hoặc Data app không có trong /system/priv-app.
• Các vấn đề cho thấy một ứng dụng Dữ liệu không hợp lệ đã được cài đặt không ngăn thiết bị khởi động nhưng ngăn việc kiểm tra bản cập nhật được kích hoạt; ví dụ: thiếu các quyền hệ thống bắt buộc hoặc ứng dụng Dữ liệu không hiển thị ContentProvider trên URI dự kiến.

Quyền đối với tệp cho các thư mục /data/misc/zoneinfo được thực thi bằng các quy tắc SELinux. Giống như mọi tệp APK, ứ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 dự kiến sẽ có một tên gói và khoá riêng biệt dành riêng cho OEM.

Tích hợp thông tin cập nhật về múi giờ

Để bật tính năng cập nhật múi giờ, các OEM thường:

• Tạo ứng dụng Dữ liệu riêng.
• Đưa ứng dụng Trình cập nhật và 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, các OEM nên xem xét chính sách, đảm bảo chất lượng và các yếu tố bảo mật sau:

• Tạo một khoá ký dành riêng cho ứng dụng cho ứng dụng Dữ liệu của họ.
• Tạo một chiến lược phát hành và quản lý phiên bản cho các bản cập nhật múi giờ để biết những thiết bị nào sẽ được cập nhật và cách các thiết bị đó có thể đảm bảo rằng các bản cập nhật chỉ được cài đặt trên những thiết bị cần chúng. Ví dụ: OEM 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ó các ứng dụng Dữ liệu khác nhau cho các thiết bị khác nhau. Quyết định này ảnh hưởng đến việc chọn tên gói, có thể là mã phiên bản được dùng và chiến lược kiểm thử chất lượng.
• Tìm hiểu xem họ có muốn sử dụng dữ liệu múi giờ Android gốc từ AOSP hay tạo dữ liệu của riêng họ.

Tạo một ứng dụng Dữ liệu

AOSP bao gồm tất cả mã nguồn và quy tắc xây 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. Các mẫu ví dụ bao gồm cả mục tiêu bản dựng cho APK ứng dụng Dữ liệu thực và các mục tiêu bổ sung để tạo phiên bản kiểm thử của ứng dụng Dữ liệu.

Các 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à các thông tin khác của riêng họ. Tuy nhiên, vì không thể chạy ứng dụng Dữ liệu, nên biểu tượng này chỉ xuất hiện trên màn hình Cài đặt > Ứng dụng.

Ứng dụng Data được thiết kế để tạo bằng bản dựng tapas. Bản dựng này tạo ra các tệp APK phù hợp để thêm vào ảnh hệ thống (cho bản phát hành ban đầu) và được ký cũng như phân phối thông qua một cửa hàng ứng dụng (cho các bản cập nhật tiếp theo). Để biết thông tin chi tiết về cách sử dụng tapas, hãy xem bài viết Tạo ứng dụng Dữ liệu bằng tapas.

Các 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 một thiết bị trong /system/priv-app. Để đưa các APK tạo sẵn (do quy trình tạo tapas tạo ra) vào hình ảnh hệ thống, các OEM có thể sao chép các tệp ví dụ trong packages/apps/TimeZoneData/oem_template/data_app_prebuilt. Các mẫu ví dụ cũng bao gồm các mục tiêu bản dựng để đưa các phiên bản kiểm thử của ứng dụng Dữ liệu vào bộ kiểm thử.

Đưa ứng dụng Trình cập nhật và Dữ liệu vào ảnh hệ thống

Các OEM phải đặt APK của ứng dụng Trình cập nhật và Dữ liệu trong thư mục /system/priv-app của hình ảnh hệ thống. Để làm việc 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à các mục tiêu được tạo sẵn của ứng dụng Dữ liệu.

Ứng dụng Trình cập nhật phải được ký bằng khoá nền tảng và được đưa vào dưới dạng bất kỳ ứng dụng hệ thống nào khác. Mục tiêu được xác định trong packages/apps/TimeZoneUpdater dưới dạng TimeZoneUpdater. Việc đưa ứng dụng Dữ liệu vào là dành riêng cho OEM và phụ thuộc vào tên mục tiêu được chọn cho bản dựng trước.

Đị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 đè các thuộc tính cấu hình được xác định trong frameworks/base/core/res/res/values/config.xml.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Các 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 hoặc hình ảnh khác) vì thiết bị được định cấu hình sai có thể từ chối khởi động. Nếu các chế độ ghi đè cấu hình nằm trong hình ảnh của nhà cung cấp, thì việc cập nhật lên một hình ảnh hệ thống không có ứng dụng Dữ liệu (hoặc có tên gói ứng dụng Dữ liệu/Ứng dụng cập nhật khác) sẽ được coi là cấu hình sai.

Kiểm thử xTS

xTS đề cập đến mọi bộ kiểm thử dành riêng cho OEM tương tự như các bộ kiểm thử Android tiêu chuẩn sử dụng Tradefed (chẳng hạn như CTS và VTS). Các OEM có bộ kiểm thử như vậy có thể thêm các kiểm thử cập nhật múi giờ của Android được cung cấp ở các vị trí sau:

• packages/apps/TimeZoneData/testing/xts bao gồm mã cần thiết cho hoạt động kiểm thử chức năng tự động cơ bản.
• packages/apps/TimeZoneData/oem_template/xts chứa cấu trúc thư mục mẫu để đưa các quy trình kiểm thử vào một bộ xTS tương tự như Tradefed. Giống như các thư mục mẫu khác, các OEM dự kiến sẽ sao chép và tuỳ chỉnh theo nhu cầu của họ.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt chứa cấu hình thời gian tạo để thêm các APK kiểm thử dựng sẵn mà hoạt động kiểm thử yêu cầu.

Tạo thông tin cập nhật về múi giờ

Khi IANA phát hành một bộ quy tắc mới về múi giờ, nhóm thư viện cốt lõi Android sẽ tạo các bản vá để cập nhật các bản phát hành trong AOSP. Các OEM sử dụng hệ thống Android gốc và các tệp phân phối có thể chọn các cam kết này, sử dụng chúng để tạo một phiên bản mới của ứng dụng Dữ liệu, sau đó phát hành phiên bản mới để cập nhật các thiết bị của họ trong quá trình sản xuất.

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, nên các OEM phải tạo một phiên bản mới của ứng dụng Dữ liệu cho mọi bản phát hành Android được hỗ trợ mà OEM muốn cập nhật. Ví dụ: nếu muốn cung cấp bản cập nhật cho các thiết bị Android 8.1, 9 và 10, thì nhà sản xuất thiết bị gốc phải hoàn tất quy trình này 3 lần.

Bước 1: Cập nhật tệp dữ liệu hệ thống/múi giờ và tệp dữ liệu bên ngoài/icu

Ở bước này, các OEM sẽ lấy các cam kết Android chung cho system/timezone và external/icu từ các nhánh release-dev trong AOSP rồi áp dụng các cam kết đó vào bản sao mã nguồn Android của họ.

Bản vá AOSP 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. Những OEM cần thực hiện các bản sửa lỗi bổ sung tại địa phương có thể sửa đổi các tệp đầu vào rồi sử dụng các tệp trong system/timezone/input_data và external/icu để tạo tệp trong output_data.

Tệp quan trọng nhất là system/timezone/output_data/distro/distro.zip. Tệp này sẽ tự động được thêm vào khi bạn tạo APK của ứ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

Trong bước này, OEM sẽ cập nhật mã phiên bản của ứng dụng Dữ liệu. Bản dựng sẽ 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à được dùng để thay thế ứng dụng Dữ liệu đã tải sẵn hoặc ứng dụng Dữ liệu do một bản cập nhật trước đó cài đặt trên thiết bị.

Khi tạo ứ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 được á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 kiểm thử phải cao hơn phiên bản hình ảnh hệ thống). Để biết thông tin chi tiết, hãy xem ví dụ về lược đồ chiến lược mã phiên bản; nếu bạn sử dụng lược đồ ví dụ hoặc một lược đồ tương tự, thì bạn không cần cập nhật mã phiên bản kiểm thử vì các mã này chắc chắn 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

Trong bước này, OEM sẽ tạo lại APK bằng cách sử dụng tapas, ký APK đã tạo, 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 thiết bị đã phát hành), hãy gửi các tệp APK mới trong thư mục đượ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à các kiểm thử xTS có các tệp APK mới nhất. Các OEM nên kiểm tra để đảm bảo tệp mới hoạt động đúng cách (tức là tệp đó vượt qua CTS và mọi kiểm thử tự động và thủ công dành riêng cho OEM).
• Đối với những thiết bị đã phát hành nhưng không còn nhận được bản cập nhật hệ thống, APK đã ký có thể chỉ được phát hành thông qua một cửa hàng ứng dụng.

Các OEM chịu trách nhiệm đảm bảo chất lượng và kiểm thử ứng dụng Dữ liệu đã cập nhật 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ó chiến lược quản lý phiên bản phù hợp để đảm bảo rằng các thiết bị nhận được tệp APK chính xác. Ví dụ: nếu bạn nhận được một bản cập nhật hệ thống có chứa tệp APK cũ hơn tệp APK được 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 những thông tin sau:

• Phiên bản định dạng distro (lớn + nhỏ)
• Số phiên bản tăng dần (không rõ ràng)

Hiện tại, cấp độ API nền tảng có mối tương quan chặt chẽ với phiên bản định dạng bản 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 (điều này khiến các tệp bản phân phối không tương thích). Trong tương lai, Android có thể thay đổi điều này để một tệp distro có thể hoạt động trên nhiều bản phát hành nền tảng Android (và cấp độ API không được dùng trong sơ đồ mã phiên bản của ứng dụng Dữ liệu).

Ví dụ về chiến lược mã phiên bản

Ví dụ về sơ đồ đánh số phiên bản này đảm bảo rằng các phiên bản định dạng phân phối cao hơn sẽ thay thế các 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 các thiết bị cũ không nhận được những phiên bản có phiên bản định dạng bản phân phối cao hơn khả năng xử lý của chúng.

Hình 6. Ví dụ về chiến lược mã phiên bản.

Lược đồ này có thể được đóng gói tốt hơn nếu sử dụng số nhị phân thay vì số thập phân, nhưng lược đồ này có ưu điểm là người dùng có thể đọc được. Nếu hết dải số đầy đủ, tên gói ứng dụng Dữ liệu có thể thay đổi.

Tên phiên bản là một thông tin chi tiết mà con người có thể đọc được, ví dụ: major=001,minor=001,iana=2017a, revision=1,respin=2. Ví dụ được minh hoạ trong bảng sau.

• Ví dụ 1 và 2 cho thấy 2 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 cao hơn 1 về số học, điều này là cần thiết để đảm bảo rằng các thiết bị mới hơn nhận được các phiên bản định dạng cao hơ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/bản vá 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 2017b cho O-MR1 và P. Có giá trị số cao hơn, chúng thay thế các bản phát hành trước đó của IANA/các bản sửa đổi Android của những phiên bản tiền nhiệm tương ứng.
• Ví dụ 6 và 7 cho thấy các bản phát hành 2018a cho O-MR1 và P.
• Ví dụ 8 minh hoạ cách sử dụng Y để thay thế hoàn toàn lược đồ Y=0.
• Ví dụ 9 minh hoạ việc sử dụng khoảng trống giữa 3 và 4 để quay lại apk.

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 ảnh hệ thống, nên 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. Một thiết bị đã cài đặt phiên bản O-MR1 trong /data, sau đó nhận được bản cập nhật hệ thống lên P sẽ sử dụng phiên bản /system thay vì phiên bản O-MR1 trong /data vì phiên bản P luôn cao hơn mọi ứng dụng dành cho O-MR1.

Tạo ứng dụng Data bằng tapas

Các 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ờ và định cấu hình hình ảnh hệ thống một cách chính xác. Ứng dụng Dữ liệu được thiết kế để tạo bằng bản dựng tapas. Bản dựng này tạo ra các tệp APK phù hợp để thêm vào ảnh hệ thống (cho bản phát hành ban đầu) và được ký cũng như phân phối thông qua một 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 rút gọn của hệ thống bản dựng Android, sử dụng một 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 ứng dụng. Các OEM quen thuộc với hệ thống bản dựng Android thông thường sẽ nhận ra các tệp bản dựng từ bản dựng nền tảng Android thông thường.

Tạo tệp kê khai

Cây nguồn rút gọn thường đạt được bằng một tệp kê khai tuỳ chỉnh chỉ đề cập đến các dự án Git mà hệ thống tạo bản dựng cần và để tạo ứng dụng. Sau khi làm theo hướng dẫn trong phần Tạo ứng dụng Dữ liệu, OEM phải có ít nhất 2 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 các tệp APK kiểm thử mà các 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 để đưa vào bản dựng hình ảnh hệ thống và các 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ã kê khai sau đây chứa bộ dự án Git tối thiểu cần thiết để hỗ trợ bản dựng O-MR1 của ứng dụng Dữ liệu múi giờ. Các OEM phải thêm các 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 nhánh khác nhau cho 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.sh
tapas
make -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 ra các tệp trong thư mục out/dist để kiểm thử. Bạn có thể đặt các tệp này vào thư mục prebuilts để đưa vào ảnh hệ thống và/hoặc phân phối thông qua một cửa hàng ứng dụng cho các thiết bị tương thích.