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 deprecates thời cơ chế cập nhật dữ liệu khu APK-based (có sẵn trong Android 8.1 và Android 9) và thay thế nó bằng một cơ chế cập nhật mô-đun APEX-based . 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 một bản cập nhật để các cơ sở dữ liệu Time Zone phát hành một bản cập nhật để đáp ứng với một hoặc nhiều các chính phủ thay đổi một quy tắc múi giờ ở đất nước 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ề mô-đun, thấy Modular hệ thống Components .

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 chứng khoán, ngay cả những người không sử dụng tính năng này, cần thời gian quy tắc khu dữ liệu và phải xuất xưởng với một mặc định của thời gian quy tắc khu dữ liệu trong /system phân vùng. 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ã số quản lý từ libcore/ (ví dụ, java.util.TimeZone ) sử dụng tzdatatzlookup.xml tập tin.
  • Native mã thư viện trong bionic/ (ví dụ, đối với mktime , hệ thống localtime cuộc gọi) sử dụng tzdata tập tin.
  • ICU4J / ICU4C mã thư viện ở external/icu/ sử dụng ICU .dat tập tin.

Các thư viện này theo dõi các tệp lớp phủ có thể có mặt trong /data/misc/zoneinfo/current thư mục. Các tệp lớp phủ dự kiến sẽ chứa dữ liệu cải tiến quy tắc múi giờ, do đó cho phép các thiết bị được cập nhật mà không 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/ đang sử dụng /data sao chép của tzdatatzlookup.xml tập tin.
  • ICU4J / ICU4C đang sử dụng các tập tin trong /data và rơi trở lại /system file cho dữ liệu đó không phải là hiện tại (đối với các định dạng, dây cục bộ, vv).

Tệp phân phối

Distro .zip file chứa các tập tin dữ liệu cần thiết để cư trú trong /data/misc/zoneinfo/current thư mục. 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 ), đó là 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 quá trình hệ thống máy chủ và các giai đoạn thời gian hoạt động cập nhật khu vực bằng cách viết cho /data/misc/zoneinfo/staged . RulesManagerService cũng có thể thay thế hoặc xóa đã tổ chức các hoạt động.
  • TimeZoneUpdater , một ứng dụng hệ thống nonupdateable (aka ứng dụng Updater). 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 hệ thống ứng dụng updateable (còn gọi là ứng dụng dữ liệu) mang distro tập tin vào thiết bị và làm cho họ có sẵn cho các ứng dụng Updater. 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 khởi động thời gian cần thiết cho sự vận hành chính xác và an toàn thông tin 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 tính năng một cách chính xác.

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 một cửa hàng ứng dụng tải về hoặc sideload. Quá trình hệ thống máy chủ (thông qua timezone.RulesManagerServer/timezone.PackageTracker lớp) giám sát mọi thay đổi đối với cấu hình, OEM cụ thể, dữ liệu tên gói ứng dụng.

    Cập nhật ứng dụng dữ liệu
    Cập nhật ứng dụng Hình 1. Dữ liệu
  2. Hệ thống máy chủ quá trình gây nên một kiểm tra cập nhật bằng cách phát sóng một mục tiêu dự định cùng với một, sử dụng đơn độc đáo token để App Updater. 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. Kích hoạt kiểm tra cập nhật
  3. Trong quá trình kiểm tra cập nhật, ứng dụng Updater thực hiện các nhiệm 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. Dữ liệu cập nhật ứng dụng, 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
      Cập nhật ứng dụng Hình 4. Dữ liệu, nhận được thông tin về distro
  4. Ứng dụng Updater có các hành động thích hợp dựa trên thông tin mà nó 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ỡ bỏ cài đặt (điều này là rất hiếm). Ví dụ, nếu APK cập nhật trong /data là bị tàn tật hoặc gỡ bỏ cài đặt và thiết bị đang trở lại với phiên bản hiện tại /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 chỉnh
  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 tổ chức hoạt động bằng cách xử lý sáng tạo, thay thế, và / hoặc xóa các /data/misc/zoneinfo/current file trước khi các thành phần hệ thống khác đã mở ra và bắt đầu sử dụng các tập tin.
    • Kiểm tra xem các tập tin trong /data là chính xác cho các phiên bản nền tảng hiện nay, mà có thể không phải là trường hợp nếu thiết bị vừa nhận được một bản cập nhật hệ thống và phiên bản định dạng distro đã thay đổi.
    • Đảm bảo rằng các quy tắc IANA phiên bản là như nhau hoặc mới hơn so với phiên bản trong /system . Điều này bảo vệ chống lại một cập nhật hệ thống để lại một thiết bị với thời gian cũ quy tắc khu dữ liệu hơn là hiện diện trong /system hình ảnh.

độ 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 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 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; ví dụ bao gồm một Updater hoặc dữ liệu cấu hình ứng dụng xấu hoặc ứng dụng Updater hoặc dữ liệu không nằm 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 file cho /data/misc/zoneinfo thư mục được thực thi sử dụng quy tắc SELinux. Như với bất kỳ apk, ứng dụng dữ liệu phải có chữ ký của khóa tương tự sử dụng để ký /system/priv-app bản. Ứ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ả các quy định mã nguồn và xây dựng cần thiết để tạo ra một ứng dụng dữ liệu trong packages/apps/TimeZoneData , với hướng dẫn và ví dụ mẫu cho AndroidManifest.xml và các file 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, như các ứng dụng dữ liệu không thể được đưa ra, 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 dự định được xây dựng với một tapas xây dựng sản xuất gói ứng dụng phù hợp để được thêm vào hình ảnh hệ thống (đối với việc phát hành ban đầu) và có chữ ký và phân phối thông qua một cửa hàng ứng dụng (các bản cập nhật tiếp theo). Để biết chi tiết về việc sử dụng tapas, xem Building ứng dụng dữ liệu sử dụng tapas .

OEM phải cài đặt ứng dụng dựng sẵn dữ liệu trong hệ thống hình ảnh của một thiết bị trong /system/priv-app . Để đưa gói ứng dụng dựng sẵn (tạo ra bởi quá trình tapas xây dựng) trong hệ thống hình ảnh, các OEM có thể sao chép các tập tin 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 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 gói ứng dụng ứng dụng Updater và Dữ liệu trong /system/priv-app thư mục 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. Các mục tiêu được định nghĩa trong packages/apps/TimeZoneUpdater như TimeZoneUpdater . 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 tính năng cập nhật múi giờ, các OEM có thể cấu hình hệ thống máy chủ bằng cách ghi đè thuộc tính cấu hình được định nghĩa trong frameworks/base/core/res/res/values/config.xml .

Bất động sản Sự miêu tả Ghi đè bắt buộc?
config_enableUpdateableTimeZoneRules
Phải được đặt true để cho phép các RulesManagerService. đúng
config_timeZoneRulesUpdateTrackingEnabled
Phải được đặt true để có hệ thống lắng nghe để thay đổi các ứ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 các mã cần thiết cho chức năng kiểm tra tự động cơ bản.
  • packages/apps/TimeZoneData/oem_template/xts chứa một cấu trúc thư mục mẫu để bao gồm các bài kiểm tra trong một Tradefed giống như XTS suite. 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 build-time cho bao gồm các gói ứng dụng thử nghiệm trước khi xây dựng theo yêu cầu của bài kiểm tra.

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.

Bởi vì các ứng dụng dữ liệu chứa distro file quan hệ chặt chẽ với các phiên bản Android, các OEM phải tạo ra 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ột 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 cam kết chứng khoán Android cho system/timezoneexternal/icu từ các chi nhánh phát hành -dev trong AOSP và áp dụng những cam kết để sao chép của họ về mã nguồn Android.

Hệ thống / múi giờ AOSP vá chứa tập tin trong cập nhật system/timezone/input_datasystem/timezone/output_data . OEM người cần phải thực hiện thêm các bản sửa lỗi địa phương có thể sửa đổi các tập tin đầu vào sau đó sử dụng các tập tin trong system/timezone/input_dataexternal/icu để tạo ra tập tin trong output_data .

Các tập tin quan trọng nhất là system/timezone/output_data/distro/distro.zip , mà được tự động đưa vào khi các ứng dụng dữ liệu APK được xây dựng.

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. Việc xây dựng tự động nhặt distro.zip , nhưng phiên bản mới của ứng dụng dữ liệu phải có một mã số phiên bản mới vì vậy nó được công nhận là mới và được sử dụng để thay thế một ứng dụng dữ liệu cài đặt sẵn hoặc một ứng dụng dữ liệu được cài đặt trên một thiết bị bằng một bản cập nhật trước đó.

Khi xây dựng các ứng dụng dữ liệu sử dụng các file được copy từ package/apps/TimeZoneData/oem_template/data_app , bạn có thể tìm tên mã phiên bản / phiên bản áp dụng cho các gói ứng dụng trong Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Mục tương tự có thể được tìm thấy trong testing/Android.mk (tuy nhiên, các mã phiên bản thử nghiệm phải cao hơn so với phiên bản hình ảnh hệ thống). Để biết chi tiết, vui lòng xem sơ đồ ví dụ phiên bản chiến lược đang ; 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 phải đượ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ó một chiến lược phiên bản phù hợp để đảm bảo rằng thiết bị nhận được gói ứng dụng 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 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 thiết bị cũ không nhận được phiên bản với một phiên bản định dạng distro cao hơn họ có thể xử lý.

Kiểm tra phiên bản
Chiến lược mã phiên bản Hình 6. Ví dụ
Thí dụ Giá trị Mục đích
Y Để dành 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.
NS Để dành 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à một đại diện con người có thể đọc được các chi tiết, 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.
  • 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ị với một phiên bản O-MR1 cài đặt trong /data mà sau đó nhận được một bản cập nhật hệ thống để P sử dụng /system phiên bản trong ưu tiên cho phiên bản O-MR1 trong /data vì phiên bản P luôn cao hơn so với bất kỳ ứng dụng dành cho O là 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 dự định được xây dựng với một tapas xây dựng sản xuất gói ứng dụng phù hợp để được thêm vào hình ảnh hệ thống (đối với việc phát hành ban đầu) và có chữ ký và phân phối thông qua một cửa hàng ứng dụng (các bản cập nhật tiếp theo).

Tapas là một rút gọn xuống phiên bản của hệ thống xây dựng Android mà sử dụng một cây nguồn giảm để tạo ra phiên bản thể chia các ứng dụng. 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 các hướng dẫn trong Tạo một ứng dụng dữ liệu , các OEM nên có ít nhất hai dự án Git OEM cụ thể tạo ra bằng cách sử dụng các tập tin mẫu dưới packages/apps/TimeZoneData/oem_template :

  • Một dự án Git chứa các file ứng dụng chẳng hạn như biểu hiện và xây dựng các file cần thiết để tạo ra các tập tin ứng dụng APK (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, gọi tapas Êđê dựng bằng cách sử dụng 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 xây dựng thành công tạo ra các file trong out/dist thư mục để 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 dành cho các thiết bị tương thích.