Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Quy tắc múi giờ

Android 10 không dùng cơ chế cập nhật dữ liệu múi giờ dựa trên APK (khả dụng trong Android 8.1 và Android 9) và thay thế nó bằng cơ chế cập nhật mô-đun dựa trên APEX . AOSP tiếp tục bao gồm mã nền tảng cần thiết để OEM có thể bật cập nhật dựa trên APK, do đó, các thiết bị nâng cấp lên Android 10 vẫn có thể nhận được 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 các bản cập nhật mô-đun vì bản cập nhật dựa trên APK thay thế cho 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 múi 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ậ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) có chứa các múi giờ đã 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)

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 đến 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 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ập nhật múi giờ độc lập với cập nhật hình ảnh hệ thống.

Nhóm thư viện 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 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 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 vẫn kiểm soát việc đảm bảo / thử nghiệm 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 kèm theo 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 sử dụng bởi mã từ các thư viện sau 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 tzdatatzlookup.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 .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ậ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 hãy kiểm tra các vị trí sau:

  • libcore/bionic/ code 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 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ề lập 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 khác của 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). Để cập nhật thiết bị của họ, 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).

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 tới một thiết bị và cài đặt an toàn các tệp có trong đó. Việc chuyển 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 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ờ theo giai đoạn 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 (hay 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.
  • 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.
  • tzdatacheck , một nhị phân thời gian khởi động cần thiết để vận hành chính xác và an toàn các bản cập nhật múi giờ.

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 đúng tính năng chưa.

Cài đặt Distro

Quá 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 tải xuống hoặc tải xuống 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 được định cấu hình, dành riêng cho OEM.

    Cập nhật ứng dụng dữ liệu
    Hình 1. Cập nhật ứng dụng dữ liệu
  2. Quy 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ột mục đích được nhắm mục tiêu với 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 kiểm tra gần đây nhất mà nó kích hoạt đã hoàn thành; 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 bản cập nhật , ứng dụng Trình cập nhật 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.

      Quy tắc cuộc gọiManagerService
      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 và thông số kỹ thuật cột được xác định rõ ràng để 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 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 hành động khả dụng 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 nội dung và phiên bản định dạng phân phối phù hợp với thiết bị và theo từng giai đoạn cài đặt.
    • Yêu cầu gỡ cài đặt (trường hợp này hiếm). Ví dụ: nếu APK cập nhật trong /data đang bị vô hiệu hóa 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 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 Updater gọi RulesManagerService với mã thông báo kiểm tra để máy chủ hệ thống biết rằng việc 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 thực hiện bất kỳ hoạt động theo giai đoạn nào. Hệ nhị phân tzdatacheck có thể thực hiện các tác vụ sau:
    • Thực hiện hoạt động 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 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 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 distro đã 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ệ chống lại việc cập nhật hệ thống để lại một thiết bị có dữ liệu quy tắc múi giờ cũ hơn so với dữ liệu hiện có trong hình ảnh /system .

độ tin cậy

Quá trình cài đặt end-to-end là 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 các sự cố khác khiến việc kiểm tra cài đặt không hoàn thành. Trong trường hợp không thành công tốt nhất, ứng dụng Trình cập nhật 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 xấu nhất không thành công, RulesManagerService không nhận được cuộc gọi nào cả.

Để xử lý điều này, mã máy chủ hệ thống 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 cuối cùng của Ứng dụng dữ liệu là gì. Khi thiết bị ở chế độ chờ 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 kiểm tra 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, nó sẽ tự động kích hoạt kiểm tra cập nhật.

Bảo vệ

Khi được kích hoạ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 an toàn khi sử dụng.

  • Các sự cố cho biết hình ảnh hệ thống được định cấu hình không tốt ngăn thiết bị khởi động; 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 ứ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 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 cập nhật được kích hoạt; các ví dụ bao gồm 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ị Nhà cung cấp nội dung trên URI dự kiến.

Quyền tệp đối với thư mục /data/misc/zoneinfo được thực thi bằng cách sử dụng các quy tắc SELinux. Như với bất kỳ APK nào, ứng dụng Dữ liệu phải được ký bằng cùng một khóa được sử dụng để ký phiên bản /system/priv-app . Ứng dụng Dữ liệu dự kiến ​​sẽ có khóa và tên 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ờ, 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 để bậ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:

  • Tạo khóa ký dành riêng cho ứng dụng cụ thể 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 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 ảnh hưởng đến việc 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 QA.
  • Hiểu liệu 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 , 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 được thiết kế với bản dựng tapas tạo ra các APK phù hợp để thêm vào hình ảnh hệ thống (đối với bản phát hành đầu tiên) và được ký kết và phân phối thông qua cửa hàng ứng dụng (đối với 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 được tạo 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 để bao gồm các phiên bản thử nghiệm của ứng dụng Dữ liệu trong các bộ thử nghiệm.

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

OEM phải đặt APK ứng dụng cập nhật và dữ liệu trong 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 tạo 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ư bất kỳ ứng dụng hệ thống nào khác. Mục tiêu được xác định trong packages/apps/TimeZoneUpdaterTimeZoneUpdater . Việc bao gồm ứ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 trước.

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

Để kích hoạ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ự mô tả Ghi đè bắt buộc?
config_enableUpdateableTimeZoneRules
Phải được đặt thành true để kích hoạ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 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 một lần kiểm tra cập nhật được kích hoạt bởi RulesManagerService và một 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 liên tiếp được phép trước khi RulesManagerService ngừng tạo nhiều hơn. Không

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

thử nghiệm xTS

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

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 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ể nhận các cam kết này, sử dụng chúng để tạo phiên bản mới cho ứ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 phiên bản sản xuất.

Vì ứng dụng Dữ liệu chứa các tệp phân phối gắn chặt 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 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 ba lần.

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

Trong bước này, các OEM lấy các cam kết Android gốc cho system/timezoneexternal/icu từ các nhánh -dev phát hành 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 . 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 icu để tạo 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 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

Trong 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 để mã này được công nhận là mới và được sử 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 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á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 nhập 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 hình ảnh hệ thống). Để biết chi tiết, hãy xem lược đồ chiến lược mã phiên bản ví dụ ; nếu lược đồ mẫu hoặc lược đồ tương tự được sử dụng, mã phiên bản thử nghiệm không cần được cập nhật 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ý kết, thử nghiệm và phát hành

Trong bước này, 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 tạo sẵn ứng dụng Dữ liệu để đảm bảo rằng kiểm tra 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 hay không (nghĩa là nó vượt qua CTS và bất kỳ kiểm tra thủ công và tự động nào 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 lập phiên bản phù hợp để đảm bảo rằng các thiết bị nhận đúng APK. 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 Distro (chính + phụ)
  • Số phiên bản tăng dần (không rõ ràng)

Hiện tại, mức API nền tảng có tương quan chặt chẽ với phiên bản định dạng distro vì mỗi mức 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 distro 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ố lập phiên bản ví dụ 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 phiên bản có định dạng phiên bản 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
Thí dụ Giá trị Mục đích
Y Kín đáo Cho phép các chương trình / APK thử nghiệm thay thế trong tương lai. Ban đầu là (ngầm định) 0. Vì kiểu cơ bản là kiểu int 32 bit có dấu, nên lược đồ này hỗ trợ tối đa hai lầ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 3 chữ số thập phân. Định dạng distro hỗ trợ 3 chữ số thập phân nhưng chỉ có 2 chữ số được sử dụng ở đây. Nó không có khả năng đạt đến 100 với mức tăng chính 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 nhỏ 3 chữ số thập phân. Định dạng distro hỗ trợ 3 chữ số thập phân nhưng chỉ có 1 chữ số được sử dụng ở đây. Nó không có khả năng đạt được 10.
X Kín đáo Là 0 cho các bản phát hành sản xuất (và có thể khác cho các APK thử nghiệm).
ZZZZZ Số phiên bản đục 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 quảng cáo xen kẽ nếu được yêu cầu.

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

Tên phiên bản là phần trình bày chi tiết mà con người có thể đọc được, ví dụ: major=001,minor=001,iana=2017a, revision=1,respin=2 . Các ví dụ được hiển thị trong bảng sau.

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

Vì mỗi thiết bị được cung cấp một APK mặc định, có phiên bản thích hợp trong hình ả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ì nó 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 cho 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 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 được thiết kế với bản dựng tapas tạo ra các APK phù hợp để thêm vào hình ảnh hệ thống (đối với bản phát hành đầu tiên) và được ký kết và phân phối thông qua cửa hàng ứng dụng (đối với các bản cập nhật tiếp theo).

Tapas là phiên bản thu gọn của hệ thống xây dựng Android sử dụng cây nguồn thu 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 ra các tệp xây 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 với 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 tệp mẫu trong packages/apps/TimeZoneData/oem_template :

  • Dự án One 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 có thể được sử dụng bởi các thử nghiệm xTS.
  • Dự án One 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 thúc đẩy 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 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ờ. 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 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="master"
        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

Một bản dựng thành công sẽ tạo ra 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 tạo sẵn để đưa vào hình ảnh hệ thống và / hoặc phân phối thông qua cửa hàng ứng dụng cho các thiết bị tương thích.