Quy tắc múi giờ

Android 10 không còn dùng cơ chế cập nhật dữ liệu múi giờ dựa trên APK (có sẵn 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 để OEM kích hoạt các bản 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 cá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, không nên sử dụng cơ chế cập nhật APK trên thiết bị sản xuất cũng đang nhận bản cập nhật mô-đun vì bản cập nhật dựa trên APK thay thế bản cập nhật dựa trên APEX (nghĩa 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 ).

Cập nhật múi giờ (Android 10+)

Mô-đun Dữ liệu múi giờ được hỗ trợ trong Android 10 trở lên cập nhật giờ tiết kiệm ánh sáng ban ngày (DST) và múi giờ trên thiết bị Android, chuẩn hóa 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át hành bản cập nhật để 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ị 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 cập nhật.
  3. Thiết bị của người dùng cuối tải xuống bản cập nhật, 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ị chứa dữ liệu múi giờ mới từ bản cập nhật.

Để biết 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ị xóa hoàn toàn khỏi Android 14 trở đi và không thể tìm thấy trong mã nguồn. Các đố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, 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 tới các 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 các bản cập nhật kịp thời (do đó kéo dài thời gian sử dụng hữu ích của thiết bị Android) và cho phép các đối tác Android kiểm tra các bản cập nhật múi giờ một cách độ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 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 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 của riêng họ nếu muốn. Trong mọi trường hợp, OEM giữ quyền kiểm soát việc đảm bảo/kiểm tra chất lượng, thời gian và khởi chạy các bản cập nhật quy tắc múi giờ cho các thiết bị được hỗ trợ của họ.

Mã nguồn và dữ liệu múi giờ 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 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 . Dữ liệu này sau đó được mã từ các thư viện sau trong cây nguồn Android sử dụng:

  • Mã được quản lý từ libcore/ (ví dụ: java.util.TimeZone ) sử dụng các tệp tzdatatzlookup.xml .
  • Mã thư viện gốc trong bionic/ (ví dụ: đối với mktime , lệnh gọi hệ thống giờ địa phương) 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, do đó cho phép các 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ờ trước tiên hãy kiểm tra các vị trí sau:

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

Tệp phân phối

Các tệp distro .zip 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, yêu cầu nền tảng Android và các thay đổi phát hành khác. 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). Để luôn cập nhật thiết bị của mình, OEM có thể sử dụng các tệp phân phối này hoặc tạo tệp riêng của họ bằng cách sử dụng cây nguồn Android (chứa các tập lệnh và các 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ờ

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 thiết bị và cài đặt an toàn các tệp có trong đó. Việc chuyển giao và cài đặt yêu cầu những điều sau:

  • Chức năng dịch vụ nền tảng ( timezone.RulesManagerService ), bị tắt theo mặc định. OEM phải kích hoạ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à thực hiện các hoạt động 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 xóa các hoạt động đã được dàn dựng.
  • 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 ). 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.
  • 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 ) mang các tệp phân phối đến thiết bị và cung cấp chúng 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 , một 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ờ 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 tra được cung cấp để cho phép các OEM tự động kiểm tra xem họ đã bật tính năng này một cách chính xác chưa.

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

Quá trình cài đặt distro bao gồm các bước sau:

  1. Ứng dụng dữ liệu được cập nhật thông qua tải xuống hoặc tải từ cửa hàng ứng dụng. Quá 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 đã được định cấu hình.

    Cập nhật ứng dụng dữ liệu
    Hình 1. Cập nhật ứng dụng dữ liệu
  2. Quá trình máy chủ hệ thống kích hoạt kiểm tra cập nhật bằng cách truyền phát mục đích được nhắm mục tiêu bằng mã thông báo sử dụng một lần duy nhất tới Ứ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 ra để có thể xác định thời điểm hoàn thành lần kiểm tra gần đây nhất mà nó kích hoạt; bất kỳ mã thông báo nào khác đều bị bỏ qua.

    Cập nhật kích hoạt
    Hình 2. Kiểm tra cập nhật kích hoạt
  3. Trong quá trình kiểm tra 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 thiết bị hiện tại bằng cách gọi RulesManagerService.

      Dịch vụ quản lý quy tắc cuộc gọi
      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 URL ContentProvider được xác định rõ ràng và thông số cột để nhận thông tin về bản phân phối.

      Nhận thông tin 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à nó có. Các hành động có sẵ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 và nội dung định dạng phân phối phù hợp với thiết bị và tiến hành cài đặt.
    • Yêu cầu gỡ cài đặt (điều này rất hiếm). Ví dụ: nếu APK cập nhật trong /data đang bị vô hiệu hóa hoặc gỡ cài đặt và thiết bị sẽ 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 ứng dụng Dữ liệu được phát hiện là không hợp lệ.
    Trong mọi trường hợp, ứng dụng Trình cập nhật 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.

    Kiểm tra hoàn tất
    Hình 5. Kiểm tra hoàn tất
  5. Khởi động lại và tzdatacheck. Khi thiết bị khởi động tiếp theo, tệp nhị phân tzdatacheck sẽ thực thi mọi hoạt động theo giai đoạn. Tệp nhị phân tzdatacheck có thể thực hiện các tác vụ sau:
    • Thực hiện thao tác theo giai đoạn bằng cách xử lý việc tạo, thay thế và/hoặc xóa 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 xem các tệp trong /data có đúng với phiên bản nền tảng hiện tại hay không, đ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 giống hoặc mới hơn phiên bản trong /system . Điều này bảo vệ khỏi bản cập nhật hệ thống khiến thiết bị có dữ liệu quy tắc múi giờ cũ hơn dữ liệu có trong hình ảnh /system .

độ tin cậy

Quá trình cài đặt từ đầu đến cuối không đồng bộ và được chia thành ba 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ể bị mất nguồn, hết dung lượng ổ đĩa hoặc gặp sự cố 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 nhất, ứng dụng Trình cập nhật sẽ thông báo cho máy chủ hệ thống rằng nó không thành công; trong trường hợp không thành công nhất, RulesManagerService không nhận được cuộc gọi nào cả.

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

Bảo vệ

Khi được bật, mã RulesManagerService trong máy chủ hệ thống sẽ thực hiện một số kiểm tra để đảm bảo rằng hệ thống được sử dụng an toàn.

  • Các sự cố cho thấy hình ảnh hệ thống được cấu hình kém sẽ ngăn cản việc khởi động thiết bị; các ví dụ bao gồm cấu hình ứng dụng Dữ liệu hoặc Trình cập nhật không hợp lệ hoặc Trình cập nhật hoặc ứng dụng Dữ liệu không có trong /system/priv-app .
  • Các sự cố cho thấy một ứng dụng Dữ liệu xấu đã được cài đặt không ngăn thiết bị khởi động nhưng ngăn quá trình kích hoạt kiểm tra cập nhật; các ví dụ bao gồm thiếu quyền hệ thống cần thiết hoặc ứng dụng Dữ liệu không hiển thị ContentProvider trên URI dự kiến.

Quyền của tệp đối với thư mục /data/misc/zoneinfo được thực thi bằng các quy tắc SELinux. Giống như bất kỳ APK nào, ứng dụng Dữ liệu phải được ký bằng chính khóa dùng để ký phiên bản /system/priv-app . Ứng dụng Dữ liệu dự kiến ​​​​sẽ có tên và khóa gói dành riêng cho OEM.

Tích hợp cập nhật 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 của riêng họ.
  • Bao gồm các ứng dụng Trình cập nhật và Dữ liệu trong bản dựng hình ảnh hệ thống.
  • Định cấu hình máy chủ hệ thống để kích hoạt RulesManagerService.

Chuẩn bị

Trước khi bắt đầu, OEM nên xem xét các cân nhắc về chính sách, đảm bảo chất lượng và bảo mật sau đây:

  • Tạo khóa ký dành riêng cho ứng dụng dành riêng cho ứng dụng Dữ liệu của họ.
  • Tạo chiến lược phát hành và lập phiên bản cho các bản cập nhật theo múi giờ để hiểu thiết bị nào sẽ được cập nhật và cách chúng có thể đảm bảo rằng các bản cập nhật chỉ được cài đặt trên các 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ả cá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 tác động đến việc lựa chọn tên gói, có thể cả mã phiên bản được sử dụng và chiến lược QA.
  • 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 xây 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 thử nghiệm của ứng dụng Dữ liệu.

OEM có thể tùy chỉnh ứng dụng Dữ liệu bằng biểu tượng, tên, bản dịch và các chi tiết khác của riêng họ. Tuy nhiên, vì không thể khởi chạy ứng dụng Dữ liệu nên biểu tượng chỉ xuất hiện trong màn hình Cài đặt > Ứng dụng .

Ứng dụng Dữ liệu dự kiến ​​sẽ được xây dựng bằng bản dựng tapas nhằm 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) cũng như đượ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 chi tiết về cách sử dụng tapas, hãy xem Xây dựng ứng dụng Dữ liệu bằng tapas .

OEM phải cài đặt ứng dụng Dữ liệu dựng sẵn trong hình ảnh hệ thống của thiết bị trong /system/priv-app . Để đưa các APK dựng sẵn (được tạo bởi quá trình xây dựng tapas) 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 xây dựng để đưa các phiên bản thử nghiệm của ứng dụng Dữ liệu vào bộ thử nghiệm.

Bao gồm các ứng dụng Cập nhật và Dữ liệu trong hình ảnh hệ thống

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

Cấu hình máy chủ hệ thống

Để bật 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 .

Tài sản Sự miêu tả Cần ghi đè?
config_enableUpdateableTimeZoneRules
Phải được đặt thành true để bật RulesManagerService. Đúng
config_timeZoneRulesUpdateTrackingEnabled
Phải được đặt thành true để hệ thống lắng nghe các thay đổi đối với ứng dụng Dữ liệu. Đúng
config_timeZoneRulesDataPackage
Tên gói của ứng dụng Dữ liệu dành riêng cho OEM. Đúng
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 kể từ khi kích hoạt quy trình kiểm tra cập nhật bởi RulesManagerService cho đến khi phản hồi cài đặt, gỡ cài đặt hoặc không làm gì cả. Sau thời điểm này, một kích hoạt độ tin cậy tự phát có thể được tạo ra. KHÔNG
config_timeZoneRulesCheckRetryCount
Số lần kiểm tra cập nhật không thành công tuần tự được cho phép trước khi RulesManagerService ngừng tạo thêm. KHÔNG

Phần ghi đè cấu hình phải có trong hình ảnh hệ thống (không phải nhà cung cấp hoặc bên khác) vì thiết bị bị định cấu hình sai có thể từ chối khởi động. Nếu phần ghi đè cấu hình nằm trong hình ảnh nhà cung cấp thì việc cập nhật lên hình ảnh hệ thống mà không có ứng dụng Dữ liệu (hoặc với tên gói ứng dụng Dữ liệu/Trình cập nhật khác) sẽ bị coi là cấu hình sai.

thử nghiệm xTS

xTS đề cập đến bất kỳ bộ thử nghiệm dành riêng cho OEM nào tương tự như bộ thử nghiệm Android tiêu chuẩn sử dụng Tradefed (chẳng hạn như CTS và VTS). Các OEM có bộ thử nghiệm như vậy có thể thêm các thử nghiệm 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 để kiểm tra 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 để bao gồm các thử nghiệm trong bộ xTS giống như Tradefed. Cũng như các thư mục mẫu khác, OEM phải sao chép và tùy 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 xây dựng để bao gồm các APK thử nghiệm dựng sẵn mà thử nghiệm yêu cầu.

Tạo cập nhật múi giờ

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

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

Trong bước này, OEM lấy các cam kết Android gốc cho system/timezoneexternal/icu từ các nhánh phát hành -dev trong AOSP và áp dụng các cam kết đó cho 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 cập nhật trong system/timezone/input_datasystem/timezone/output_data . Các OEM cần thực hiện các bản sửa lỗi cục bộ bổ sung có thể sửa đổi các tệp đầu vào, sau đó sử dụng các tệp trong system/timezone/input_dataexternal/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 , được tự động đưa vào khi APK ứng dụng Dữ liệu được tạo.

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 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 để nó được nhận dạng là mới và được dùng để thay thế ứng dụng Dữ liệu được tải sẵn hoặc ứng dụng Dữ liệu được cài đặt trên thiết bị bằng bản cập nhật trước đó.

Khi xây dựng ứng dụng Dữ liệu bằng cách sử dụ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 :=

Các mục tương tự có thể được tìm thấy trong testing/Android.mk (tuy nhiên, mã phiên bản thử nghiệm phải cao hơn phiên bản hình ảnh hệ thống). Để biết chi tiết, hãy xem sơ đồ chiến lược mã phiên bản mẫu ; nếu sử dụng lược đồ ví dụ hoặc lược đồ tương tự thì không cần cập nhật mã phiên bản thử nghiệm vì chúng được đảm bảo cao hơn mã phiên bản thực.

Bước 3: Xây dựng lại, ký, thử nghiệm và phát hành

Ở bước này, các OEM xây dựng lại APK bằng tapas, ký APK đã tạo, sau đó kiểm tra và phát hành APK:

  • Đối với các thiết bị chưa được phát hành (hoặc khi chuẩn bị cập nhật hệ thống cho thiết bị đã phát hành), hãy gửi APK mới trong thư mục dựng sẵn của ứng dụng Dữ liệu để đảm bảo rằng các thử nghiệm hình ảnh hệ thống và xTS có APK mới nhất. OEM phải kiểm tra xem tệp mới có hoạt động chính xác không (nghĩa là nó vượt qua CTS và mọi kiểm tra thủ công và tự độ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ý chỉ có thể đượ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 đã 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 rằng các thiết bị nhận được APK chính xác. Ví dụ: nếu nhận được bản cập nhật hệ thống có chứa APK cũ hơn 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 các thông tin sau:

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

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 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 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 có định dạng phân phối cao hơn sẽ thay thế các phiên bản có đị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 phiên bản có phiên bản có định dạng phân phối cao hơn mức chúng có thể xử lý.

Kiểm tra phiên bản
Hình 6. Ví dụ về chiến lược mã phiên bản
Ví dụ Giá trị Mục đích
Y Kín đáo Cho phép các kế hoạch/APK thử nghiệm thay thế trong tương lai. Ban đầu nó (ngầm) là 0. Bởi vì kiểu cơ bản là kiểu int 32-bit có dấu, lược đồ này hỗ trợ tối đa hai bản sửa đổi lược đồ đánh số trong tương lai.
01 Phiên bản định dạng chính 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. Khó có thể đạt tới 100 do mức tăng lớn dự kiến ​​cho mỗi cấp độ API. Phiên bản chính 1 tương đương với 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ỉ sử dụng 1 chữ số ở đây. Khó có thể đạt được 10.
X Kín đáo Là 0 đối với bản phát hành chính thức (và có thể khác đối với APK thử nghiệ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 thực hiện cập nhật xen kẽ nếu cần.

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

Tên phiên bản là sự thể hiện 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 hiển thị trong bảng sau.

# Mã phiên bản phiên bản minSdk {Phiên bản định dạng chính},{Phiên bản định dạng phụ},{Phiên bản quy tắc IANA},{Bản sửa đổi}
1 11000010 O-MR1 chính=001,phụ=001,iana=2017a,sửa đổi=1
2 21000010 P chính=002,phụ=001,iana=2017a,sửa đổi=1
3 11000020 O-MR1 chính=001,phụ=001,iana=2017a,sửa đổi=2
4 11000030 O-MR1 chính=001,phụ=001,iana=2017b,sửa đổi=1
5 21000020 P chính=002,phụ=001,iana=2017b,sửa đổi=1
6 11000040 O-MR1 chính=001,phụ=001,iana=2018a,sửa đổi=1
7 21000030 P chính=002,phụ=001,iana=2018a,sửa đổi=1
số 8 1123456789 - -
9 11000021 O-MR1 chính=001,phụ=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 cao hơn 1 về mặt số lượng, điều này cần thiết để đảm bảo rằng các thiết bị mới hơn nhận được phiên bản có đị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 lỗi cho 1 và cao hơn 1 về mặt số lượng.
  • Ví dụ 4 và 5 hiển thị các bản phát hành 2017b cho O-MR1 và P. Với 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 đó của các phiên bản tiền nhiệm tương ứng.
  • Ví dụ 6 và 7 hiển thị bản phát hành 2018a cho O-MR1 và P.
  • Ví dụ 8 chứng tỏ việc sử dụng Y để thay thế hoàn toàn sơ đồ Y=0.
  • Ví dụ 9 minh họa việc sử dụng khoảng trống còn lại từ 3 đến 4 để quay lại gói ứng dụng.

Vì mỗi thiết bị đ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 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ó phiên bản O-MR1 được cài đặt 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 ưu tiên hơn phiên bản O-MR1 trong /data vì phiên bản P luôn cao hơn bất kỳ ứng dụng nào dành cho O- MR1.

Xây dựng ứ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ờ 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 dự kiến ​​sẽ được xây dựng bằng bản dựng tapas nhằm 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) cũng như đượ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à phiên bản rút gọn 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 xây dựng Android thông thường sẽ nhận dạng các tệp xây dựng từ bản dựng nền tảng Android thông thường.

Tạo bảng kê khai

Cây nguồn rút gọn thường đạt được bằng tệp kê khai tùy chỉnh chỉ đề cập đến các dự án Git cần thiết cho hệ thống xây dựng và để xây dựng ứng dụng. Sau khi làm theo hướng dẫn trong Tạo ứng dụng Dữ liệu , OEM phải có í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 xây dựng cho các APK thử nghiệm mà các thử nghiệm 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à thử nghiệm 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 nhóm 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 của họ (thường bao gồm một dự án có chứa chứng chỉ ký) vào bảng kê khai này và có thể định cấu hình các nhánh khác nhau tương ứng.

   <!-- 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 cây nguồn được thiết lập, 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

Quá trình xây dựng thành công sẽ tạo các tệp trong thư mục out/dist để thử nghiệm. Các tệp này có thể được đặt vào thư mục dựng 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 dành cho các thiết bị tương thích.