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 chứa mã nền tảng cần thiết để OEM có thể 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ị chính thức cũng đang nhận đượ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 bản cập nhật dựa trên APEX).

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 cập nhật giờ mùa hè (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ị.

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 sẽ chuẩn bị bản 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.
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 rồi á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 của bản cập nhật.

Để biết thông tin chi tiết về các mô-đun, hãy xem bài viết 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 nên bạn không thể tìm thấy tính năng này trong mã nguồn. Đối tác nên di chuyển hoàn toàn sang mô-đun Dòng chính của Múi giờ.

Trong Android 8.1 và Android 9, nhà sản xuất thiết bị gốc (OEM) có thể sử dụng cơ chế dựa trên APK để đẩy dữ liệu quy tắc múi giờ đã cập nhật đến các thiết bị mà không cần cập nhật hệ thống. Cơ chế này cho phép người dùng nhận được thông tin cập nhật kịp thời (do đó kéo dài thời gian hữu ích của thiết bị Android) và cho phép các đối tác Android kiểm thử thông tin cập nhật múi giờ độc lập với thông tin cập nhật hình ảnh hệ thống.

Nhóm thư viện cốt lõi của 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 thiết bị Android nguyên gốc. Nhà sản xuất thiết bị gốc (OEM) 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, nhà sản xuất thiết bị gốc (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 phát hành bản cập nhật quy tắc múi giờ cho các thiết bị được hỗ trợ.

Dữ liệu và mã nguồn múi giờ Android

Tất cả thiết bị Android nguyên 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 về múi giờ và phải đi kèm với một tập hợp dữ liệu quy tắc về múi giờ mặc định trong phân vùng /system. Sau đó, mã từ các thư viện sau trong cây nguồn Android sẽ sử dụng dữ liệu này:

• 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, các lệnh gọi hệ thống theo giờ địa phương) sẽ 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. Tệp lớp phủ dự kiến sẽ chứa dữ liệu quy tắc múi giờ đã cải tiến, từ đó cho phép cập nhật thiết bị 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ờ trước tiên sẽ kiểm tra các vị trí sau:

• 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ó sẵn (đối với các định dạng, chuỗi được bản địa hoá, v.v.).

Tệp bản 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 bản 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 về 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ợ đối với mọi bản 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). Để đảm bảo thiết bị luôn được cập nhật, OEM có thể 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à tệp khác cần thiết để tạo tệp bản 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ờ bao gồm việc truyền các tệp phân phối sang một thiết bị và cài đặt an toàn các tệp chứa trong đó. Để chuyển và cài đặt, bạn cần có:

• Chức năng dịch vụ 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. RulesManagerService chạy trong quy trình máy chủ hệ thống và các giai đoạn 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 sắp xếp.
• TimeZoneUpdater, một ứ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). 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) sẽ chuyển các tệp bản 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. 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 – tệp nhị phân thời gian 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 trê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 (Nhà sản xuất thiết bị gốc) tự động kiểm tra để đảm bảo 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:

1. Ứ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 không qua cửa hàng. 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 Data (Dữ liệu) được định cấu hình, dành riêng cho OEM.
   
   

   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 lượt kiểm tra bản cập nhật bằng cách truyền tin một ý định được nhắm mục tiêu bằng một mã thông báo duy nhất, dùng một lần đến Ứ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à nó đã tạo để có thể xác định thời điểm hoàn tất lượt kiểm tra gần đây nhất mà nó đã kích hoạt; mọi mã thông báo khác sẽ bị bỏ qua.
   
   

   Hình 2. Kích hoạt tính năng 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 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 Data 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 Trình cập nhật 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 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. RulesManagerService xác nhận lại rằng phiên bản định dạng bản phân phối và nội dung phù hợp với thiết bị và theo giai đoạn cài đặt.
   • Yêu cầu gỡ cài đặt (rất hiếm khi xảy ra). Ví dụ: nếu tệp APK đã cập nhật trong /data đang bị tắt hoặc bị 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 phát hiện thấy bản phân phối ứng dụng Data 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 hệ thống khác mở và bắt đầu sử dụng các tệp đó.
   • Kiểm tra để đảm bảo các tệp trong /data là chính xác đối với phiên bản nền tảng hiện tại. Tuy nhiên, điều này có thể không xảy ra 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 giống hoặc mới hơn phiên bản trong /system. Điều này giúp tránh trường hợp bản cập nhật hệ thống để lại thiết bị với dữ liệu quy tắc múi giờ cũ hơn so với dữ liệu trong hình ảnh /system.

Độ tin cậy

Quy trình cài đặt toàn diện không đồng bộ và được chia thành 3 quy trình hệ điều hành. Tại bất cứ thời điểm nào trong quá trình cài đặt, thiết bị có thể bị 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ý vấn đề này, mã máy chủ hệ thống theo dõi xem quá trình kiểm tra bản cập nhật đã kích hoạt có hoàn tất hay chưa và mã phiên bản được 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 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 một quy trình kiểm tra bản cập nhật chưa hoàn tất hoặc phiên bản Ứng dụng dữ liệu không mong muốn, thì ứng dụng này 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 rằng hệ thống an toàn để 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 cách sẽ ngăn thiết bị khởi động; ví dụ: cấu hình ứng dụng Trình cập nhật hoặc Dữ liệu không đúng cách hoặc ứng dụng Trình cập nhật hoặc Dữ liệu không có trong /system/priv-app.
• Các vấn đề cho thấy ứng dụng Dữ liệu không tốt đã được cài đặt không ngăn thiết bị khởi động nhưng ngăn việc kích hoạt quy trình kiểm tra bản cập nhậ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.

Các quyền đối với tệp cho 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 Data phải được ký bằng cùng một khoá dùng để ký phiên bản /system/priv-app. Ứng dụng Dữ liệu dự kiến sẽ có tên gói và khoá 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ờ, nhà sản xuất thiết bị gốc (OEM) thường:

• Tạo ứng dụng Dữ liệu của riêng họ.
• Thêm ứ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, nhà sản xuất thiết bị gốc (OEM) nên xem xét các vấn đề sau đây về chính sách, đảm bảo chất lượng và bảo mật:

• Tạo một khoá ký dành riêng cho ứng dụng cho ứng dụng Data của họ.
• Tạo chiến lược phát hành và tạo phiên bản cho 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 đảm bảo rằng bản cập nhật chỉ được cài đặt trên những thiết bị cần bản cập nhật. Ví dụ: OEM có thể muốn có một ứng dụng Dữ liệu duy nhất cho tất cả các thiết bị của họ hoặc có thể chọn có nhiều ứng dụng Dữ liệu cho nhiều thiết bị. Quyết định này ảnh hưởng đến lựa chọn tên gói, 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ọ 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 ứ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 ứng dụng Dữ liệu trong packages/apps/TimeZoneData, cùng với hướng dẫn và 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 các phiên bản kiểm thử 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à các thông tin chi tiết khác của riêng họ. Tuy nhiên, vì không thể chạy ứng dụng Data, nên biểu tượng này chỉ xuất hiện trong màn hình Settings > Apps (Cài đặt > Ứng dụng).

Ứng dụng Data (Dữ liệu) được tạo bằng bản dựng tapas tạo ra các tệp APK phù hợp để thêm vào hình ảnh hệ thống (cho bản phát hành ban đầu) và được 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). Để biết thông tin chi tiết về cách sử dụng món tapas, vui lòng xem phần Xây dựng ứng dụng Dữ liệu bằng món tapas.

Nhà sản xuất thiết bị gố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 tệp APK tạo sẵn (do quy trình xây dựng tapas tạo ra) vào hình ảnh hệ thống, OEM có thể sao chép các tệp mẫu 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 Data vào bộ kiểm thử.

Thêm ứng dụng Trình cập nhật và Dữ liệu vào hình ảnh hệ thống

Nhà sản xuất thiết bị gốc (OEM) phải đặt tệp APK của Trình cập nhật và ứng dụng Dữ liệu trong thư mục /system/priv-app của hình ảnh hệ thống. Để làm điều này, bản dựng ảnh hệ thống phải bao gồm rõ ràng các mục tiêu tạo sẵn của ứng dụng Trình cập nhật và ứ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 như mọi ứng dụng hệ thống khác. Mục tiêu được xác định trong packages/apps/TimeZoneUpdater là TimeZoneUpdater. Việc đưa ứng dụng Data 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

Để cho phép 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 các chế độ khác) vì thiết bị được định cấu hình không chính xác có thể từ chối khởi động. Nếu 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 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 Trình cập nhật/Ứng dụng dữ liệu khác) 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 bộ kiểm thử Android tiêu chuẩn sử dụng Tradefeed (chẳng hạn như CTS và VTS). Nhà sản xuất thiết bị gốc có bộ kiểm thử như vậy có thể thêm hoạt động kiểm thử cập nhật múi giờ Android được cung cấp ở các vị trí sau:

• packages/apps/TimeZoneData/testing/xts bao gồm mã cần thiết cho 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 chương trình kiểm thử vào bộ xTS giống như Tradefed. Cũng như các thư mục mẫu khác, nhà sản xuất thiết bị gố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 tại thời điểm tạo bản dựng để đưa các APK kiểm thử tạo sẵn mà kiểm thử yêu cầu vào.

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 giờ mới, nhóm thư viện lõi Android sẽ tạo các bản vá để cập nhật bản phát hành trong AOSP. Các nhà sản xuất thiết bị gố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 thay đổi này, sử dụng các thay đổi này để tạo 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 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 liên kết chặt chẽ với các phiên bản Android, nên 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 một OEM muốn cung cấp bản cập nhật cho các thiết bị Android 8.1, 9 và 10, họ phải hoàn tất quy trình này 3 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, OEM sẽ lấy các thay đổi đã cam kết của Android cho 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 mã nguồn Android của họ.

Bản vá AOSP hệ thống/khu vực giờ chứa các tệp đã cập nhật trong system/timezone/input_data và system/timezone/output_data. Các OEM cần thực hiện thêm các bản sửa lỗi cục bộ có thể sửa đổi các tệp đầu vào, sau đó sử dụng các tệp trong system/timezone/input_data và external/icu để tạo các tệp trong output_data.

Tệp quan trọng nhất là system/timezone/output_data/distro/distro.zip. Tệp này được tự động đưa vào khi tạo APK ứng dụng Data.

Bước 2: Cập nhật mã phiên bản của ứng dụng Data

Ở bước này, OEM cập nhật mã phiên bản của ứng dụng Data. Bản dựng sẽ tự động chọn distro.zip, nhưng phiên bản mới của ứng dụng Data 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 Data được tải sẵn hoặc ứng dụng Data được cài đặt trên thiết bị bằng một bản cập nhật trước đó.

Khi tạo ứng dụng Data 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 ảnh hệ thống). Để biết thông tin chi tiết, hãy xem lược đồ chiến lược mã phiên bản mẫu; nếu bạn sử dụng lược đồ mẫu 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 được đảm bảo 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 sẽ tạo lại APK bằ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 tạo sẵn của ứng dụng dữ liệu để đảm bảo rằng hình ảnh hệ thống và hoạt động kiểm thử xTS có tệp APK mới nhất. Nhà sản xuất thiết bị gốc (OEM) nên kiểm tra để đảm bảo tệp mới hoạt động chính xác (tức là tệp này vượt qua CTS và mọi quy trình 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, APK đã ký có thể chỉ được phát hành thông qua cửa hàng ứng dụng.

Nhà sản xuất thiết bị gốc (OEM) chịu trách nhiệm đảm bảo chất lượng và kiểm thử ứng dụng Data đã 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 tạo phiên bản phù hợp để đảm bảo thiết bị nhận được đúng tệp APK. Ví dụ: nếu nhận được bản cập nhật hệ thống chứa tệp APK cũ hơn tệp APK tải xuống từ cửa hàng ứng dụng, thì bạn nên giữ lại phiên bản cửa hàng ứng dụng.

Mã phiên bản APK phải bao gồm các thông tin sau:

• Phiên bản định dạng bản phân phối (chính + phụ)
• Số phiên bản tăng dần (mờ)

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 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 (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 để 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à cấp độ API không được sử dụng trong lược đồ mã phiên bản ứng dụng Dữ liệu).

Chiến lược mã phiên bản mẫu

Lược đồ số phiên bản mẫu này đảm bảo rằng các phiên bản định dạng bản phân phối cao hơn sẽ thay thế các phiên bản định dạng bản 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 các 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.

Giao thức này có thể được đóng gói tốt hơn nếu sử dụng hệ nhị phân thay vì hệ thập phân, nhưng giao thức này có ưu điểm là người dùng có thể đọc được. Nếu hết toàn bộ phạm vi số, tên gói ứng dụng Dữ liệu có thể thay đổi.

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

• Ví dụ 1 và 2 cho thấy 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 cao hơn 1 về mặt số học, điều này cần thiết để đảm bảo rằng các thiết bị mới hơn sẽ 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/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 2017b cho O-MR1 và P. Cao hơn về mặt số, chúng thay thế các bản phát hành IANA/bản sửa đổi Android trước đó của những phiên bản trước đó.
• 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ạ cách 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 để quay lại tệp apk.

Vì mỗi thiết bị đều đi kèm với một APK phiên bản mặc định, được định phiên bản phù hợp trong hình ảnh hệ thống, nên không có nguy cơ cài đặt phiên bản O-MR1 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 hình ả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 (Dữ liệu) bằng tapas

Nhà sản xuất thiết bị gố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 Data (Dữ liệu) được 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 hình ảnh hệ thống (cho bản phát hành ban đầu) và được 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 chi tiết của hệ thống xây dựng Android, sử dụng cây nguồn rút gọn để tạo ra các phiên bản ứng dụng có thể phân phối. 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 có được bằng một tệp kê khai tuỳ chỉnh chỉ tham chiếu đến các dự án Git mà hệ thống xây dựng cần và để xây dựng ứng dụng. Sau khi làm theo hướng dẫn trong phần Tạo ứng dụng dữ liệu, OEM (Nhà sản xuất thiết bị gốc) nên 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 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 tệp 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 chương trình 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 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 tối thiểu các dự án Git cần thiết để hỗ trợ bản dựng O-MR1 của ứng dụng Dữ liệu múi giờ. Nhà sản xuất thiết bị gố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 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 tạo sẵn để đưa vào hình ảnh hệ thống và/hoặc được phân phối qua cửa hàng ứng dụng cho các thiết bị tương thích.