Bản cập nhật hệ thống A/B (không gián đoạn)

Các bản cập nhật hệ thống A/B cũ (còn gọi là bản cập nhật liền mạch) đảm bảo hệ thống khởi động có thể hoạt động vẫn còn trên ổ đĩa trong quá trình cập nhật qua mạng (OTA). Phương pháp này giúp giảm khả năng thiết bị không hoạt động sau khi cập nhật, tức là giảm số lần thay thế thiết bị và nạp lại thiết bị tại các trung tâm sửa chữa và bảo hành. Các hệ điều hành khác dành cho doanh nghiệp, chẳng hạn như ChromeOS cũng sử dụng thành công các bản cập nhật A/B.

Để biết thêm thông tin về bản cập nhật hệ thống A/B và cách hoạt động của bản cập nhật này, hãy xem phần Lựa chọn phân vùng (các khe cắm).

Bản cập nhật hệ thống A/B mang lại những lợi ích sau:

  • Bản cập nhật OTA có thể diễn ra trong khi hệ thống đang chạy mà không làm gián đoạn người dùng. Người dùng có thể tiếp tục sử dụng thiết bị của họ trong quá trình cập nhật qua mạng (OTA). Thời gian ngừng hoạt động duy nhất trong quá trình cập nhật là khi thiết bị khởi động lại vào phân vùng đĩa đã cập nhật.
  • Sau khi cập nhật, quá trình khởi động lại sẽ không mất nhiều thời gian hơn so với quá trình khởi động lại thông thường.
  • Nếu không áp dụng được bản cập nhật qua mạng (ví dụ: do bộ nhớ flash bị lỗi), thì người dùng sẽ không bị ảnh hưởng. Người dùng sẽ tiếp tục chạy hệ điều hành cũ và ứng dụng có thể thử lại việc cập nhật.
  • Nếu bản cập nhật OTA được áp dụng nhưng không khởi động được, thiết bị sẽ khởi động lại vào phân vùng cũ và vẫn dùng được. Ứng dụng có thể thử cập nhật lại.
  • Mọi lỗi (chẳng hạn như lỗi I/O) chỉ ảnh hưởng đến tập hợp phân vùng không dùng đến và có thể thử lại. Những lỗi như vậy cũng ít xảy ra hơn vì tải I/O cố ý thấp để tránh làm giảm trải nghiệm người dùng.
  • Bạn có thể truyền trực tuyến các bản cập nhật đến thiết bị A/B, không cần tải gói xuống trước khi cài đặt. Truyền phát trực tiếp có nghĩa là người dùng không cần có đủ dung lượng trống để lưu trữ gói cập nhật trên /data hoặc /cache.
  • Phân vùng bộ nhớ đệm không còn được dùng để lưu trữ các gói cập nhật qua mạng (OTA), nên bạn không cần đảm bảo phân vùng bộ nhớ đệm có đủ dung lượng cho các bản cập nhật trong tương lai.
  • dm-verity đảm bảo thiết bị sẽ khởi động một hình ảnh không bị hỏng. Nếu không khởi động được do gặp vấn đề về OTA hoặc dm-verity, thiết bị có thể khởi động lại vào một hình ảnh cũ. (Android Xác minh quy trình khởi động không yêu cầu bản cập nhật A/B.)

Giới thiệu về bản cập nhật hệ thống A/B

Các bản cập nhật A/B yêu cầu thay đổi cả ứng dụng và hệ thống. Tuy nhiên, máy chủ gói OTA không cần thay đổi: các gói cập nhật vẫn được phân phát qua HTTPS. Đối với các thiết bị sử dụng cơ sở hạ tầng OTA của Google, mọi thay đổi về hệ thống đều nằm trong AOSP và mã ứng dụng do Dịch vụ Google Play cung cấp. Các OEM không sử dụng cơ sở hạ tầng OTA của Google sẽ có thể sử dụng lại mã hệ thống AOSP nhưng sẽ cần cung cấp ứng dụng riêng.

Đối với các OEM cung cấp ứng dụng khách của riêng mình, ứng dụng khách cần phải:

  • Quyết định thời điểm cập nhật. Vì các bản cập nhật A/B diễn ra ở chế độ nền, nên chúng không còn do người dùng khởi tạo nữa. Để tránh làm gián đoạn người dùng, bạn nên lên lịch cập nhật khi thiết bị ở chế độ bảo trì không hoạt động, chẳng hạn như qua đêm và khi kết nối Wi-Fi. Tuy nhiên, ứng dụng có thể sử dụng bất kỳ phương pháp phỏng đoán nào bạn muốn.
  • Kiểm tra với các máy chủ gói OTA của bạn và xác định xem có bản cập nhật hay không. Phần này hầu hết sẽ giống với mã ứng dụng hiện có của bạn, ngoại trừ việc bạn sẽ muốn báo hiệu rằng thiết bị hỗ trợ A/B. (Ứng dụng Google cũng có nút Kiểm tra ngay để người dùng kiểm tra xem có bản cập nhật mới nhất hay không.)
  • Gọi update_engine bằng URL HTTPS cho gói cập nhật của bạn, giả sử có một gói cập nhật. update_engine sẽ cập nhật các khối thô trên phân vùng hiện không dùng đến khi truyền gói cập nhật.
  • Báo cáo việc cài đặt thành công hay thất bại cho các máy chủ của bạn, dựa trên mã kết quả update_engine. Nếu bản cập nhật được áp dụng thành công, update_engine sẽ yêu cầu trình tải khởi động khởi động vào hệ điều hành mới vào lần khởi động lại tiếp theo. Trình tải khởi động sẽ quay về hệ điều hành cũ nếu hệ điều hành mới không khởi động được, vì vậy, bạn không cần làm gì cả. Nếu quá trình cập nhật không thành công, ứng dụng cần quyết định thời điểm (và liệu có) thử lại hay không, dựa trên mã lỗi chi tiết. Ví dụ: một ứng dụng tốt có thể nhận ra rằng gói OTA một phần ("diff") không thành công và thử gói OTA đầy đủ thay thế.

Khách hàng có thể làm thêm các bước sau (không bắt buộc):

  • Hiện một thông báo yêu cầu người dùng khởi động lại. Nếu muốn triển khai một chính sách khuyến khích người dùng thường xuyên cập nhật, thì bạn có thể thêm thông báo này vào ứng dụng của mình. Nếu ứng dụng không nhắc người dùng, thì người dùng sẽ nhận được bản cập nhật vào lần khởi động lại tiếp theo. (Ứng dụng của Google có độ trễ có thể định cấu hình cho mỗi bản cập nhật.)
  • Hiện thông báo cho người dùng biết họ đã khởi động vào phiên bản hệ điều hành mới hay chưa, hoặc họ có được phép làm như vậy hay không nhưng lại quay về phiên bản hệ điều hành cũ. (Ứng dụng khách của Google thường không làm cả hai.)

Về phía hệ thống, bản cập nhật hệ thống A/B ảnh hưởng đến những nội dung sau:

  • Lựa chọn phân vùng (các khe cắm), trình nền update_engine và các lượt tương tác với trình tải khởi động (được mô tả bên dưới)
  • Quy trình tạo và tạo gói cập nhật qua mạng không dây (OTA) (được mô tả trong phần Triển khai bản cập nhật A/B)

Chọn phân vùng (các khe cắm)

Bản cập nhật hệ thống A/B sử dụng 2 nhóm phân vùng, được gọi là khe (thường là khe A và khe B). Hệ thống chạy từ khe hiện tại trong khi hệ thống đang chạy không truy cập vào các phân vùng trong khe không dùng trong quá trình hoạt động bình thường. Phương pháp này giúp các bản cập nhật có khả năng chống lỗi bằng cách giữ khe cắm không dùng đến làm phương án dự phòng: Nếu xảy ra lỗi trong hoặc ngay sau khi cập nhật, hệ thống có thể quay lại khe cắm cũ và tiếp tục hoạt động. Để đạt được mục tiêu này, không có phân vùng nào mà khe hiện tại sử dụng được cập nhật trong quá trình cập nhật qua mạng (bao gồm cả các phân vùng chỉ có một bản sao).

Mỗi khe cắm có một thuộc tính bootable (có thể khởi động) cho biết liệu khe cắm có chứa một hệ thống chính xác mà thiết bị có thể khởi động hay không. Khe cắm hiện tại có thể khởi động khi hệ thống đang chạy, nhưng khe cắm kia có thể có phiên bản cũ (vẫn chính xác) của hệ thống, phiên bản mới hơn hoặc dữ liệu không hợp lệ. Bất kể khe cắm hiện tại là gì, sẽ có một khe cắm là khe cắm đang hoạt động (khe cắm mà trình tải khởi động sẽ khởi động từ lần khởi động tiếp theo) hoặc khe cắm ưu tiên.

Mỗi khe cắm cũng có một thuộc tính successful (thành công) do không gian người dùng đặt. Thuộc tính này chỉ liên quan nếu khe cắm cũng có thể khởi động. Một phân vùng hoạt động thành công phải có khả năng khởi động, chạy và tự cập nhật. Trình tải khởi động phải đánh dấu một khe cắm có thể khởi động nhưng không được đánh dấu là thành công (sau khi thực hiện một số lần thử khởi động từ khe cắm đó) là không thể khởi động, bao gồm cả việc thay đổi khe cắm đang hoạt động thành một khe cắm có thể khởi động khác (thường là khe cắm chạy ngay trước khi cố gắng khởi động vào khe cắm mới, đang hoạt động). Thông tin cụ thể về giao diện được xác định trong boot_control.h.

Cập nhật trình nền của công cụ

Bản cập nhật hệ thống A/B sử dụng một trình nền ở chế độ nền có tên là update_engine để chuẩn bị hệ thống khởi động vào một phiên bản mới, đã cập nhật. Trình nền này có thể thực hiện các thao tác sau:

  • Đọc từ các phân vùng A/B của khe cắm hiện tại và ghi mọi dữ liệu vào các phân vùng A/B của khe cắm chưa dùng theo hướng dẫn của gói OTA.
  • Gọi giao diện boot_control trong một quy trình làm việc được xác định trước.
  • Chạy chương trình sau khi cài đặt từ phân vùng mới sau khi ghi tất cả các phân vùng khe cắm không dùng đến, theo hướng dẫn của gói OTA. (Để biết thông tin chi tiết, hãy xem phần Sau khi cài đặt).

Vì trình nền update_engine không tham gia vào chính quy trình khởi động, nên trình nền này bị hạn chế về những việc có thể làm trong quá trình cập nhật theo các chính sách và tính năng SELinux trong ngăn hiện tại (các chính sách và tính năng như vậy không thể cập nhật cho đến khi hệ thống khởi động vào phiên bản mới). Để duy trì một hệ thống mạnh mẽ, quy trình cập nhật không được sửa đổi bảng phân vùng, nội dung của các phân vùng trong khe hiện tại hoặc nội dung của các phân vùng không phải A/B không thể xoá sạch dữ liệu bằng cách đặt lại về trạng thái ban đầu.

Cập nhật nguồn công cụ

Nguồn update_engine nằm trong system/update_engine. Các tệp dexopt OTA A/B được chia thành installd và một trình quản lý gói:

Để biết ví dụ minh hoạ, hãy tham khảo /device/google/marlin/device-common.mk.

Cập nhật nhật ký của công cụ

Đối với các bản phát hành Android 8.x trở xuống, bạn có thể tìm thấy nhật ký update_engine trong logcat và trong báo cáo lỗi. Để nhật ký update_engine có sẵn trong hệ thống tệp, hãy vá các thay đổi sau vào bản dựng của bạn:

Những thay đổi này sẽ lưu một bản sao của nhật ký update_engine gần đây nhất vào /data/misc/update_engine_log/update_engine.YEAR-TIME. Ngoài nhật ký hiện tại, 5 nhật ký gần đây nhất sẽ được lưu trong /data/misc/update_engine_log/. Người dùng có mã nhận dạng nhóm log sẽ có thể truy cập vào nhật ký hệ thống tệp.

Tương tác với trình tải khởi động

boot_control HAL được update_engine (và có thể là các trình nền khác) dùng để hướng dẫn trình tải khởi động khởi động từ đâu. Sau đây là các trường hợp ví dụ phổ biến và trạng thái liên quan:

  • Trường hợp bình thường: Hệ thống đang chạy từ khe cắm hiện tại, có thể là khe cắm A hoặc B. Cho đến nay, chưa có nội dung cập nhật nào được áp dụng. Khe cắm hiện tại của hệ thống có thể khởi động, thành công và là khe cắm đang hoạt động.
  • Đang cập nhật: Hệ thống đang chạy từ khe cắm B, vì vậy khe cắm B là khe cắm có thể khởi động, thành công và đang hoạt động. Vị trí A được đánh dấu là không thể khởi động vì nội dung của vị trí A đang được cập nhật nhưng chưa hoàn tất. Việc khởi động lại ở trạng thái này sẽ tiếp tục khởi động từ khe B.
  • Đã áp dụng bản cập nhật, đang chờ khởi động lại: Hệ thống đang chạy từ khe B, khe B có thể khởi động và thành công, nhưng khe A được đánh dấu là đang hoạt động (và do đó được đánh dấu là có thể khởi động). Khe A chưa được đánh dấu là thành công và bộ tải khởi động phải thực hiện một số lần cố gắng khởi động từ khe A.
  • Hệ thống khởi động lại vào bản cập nhật mới: Hệ thống đang chạy từ khe A lần đầu tiên, khe B vẫn có thể khởi động và thành công trong khi khe A chỉ có thể khởi động và vẫn hoạt động nhưng không thành công. Một trình nền không gian người dùng, update_verifier, sẽ đánh dấu khe A là thành công sau khi thực hiện một số bước kiểm tra.

Hỗ trợ cập nhật truyền phát trực tiếp

Thiết bị của người dùng không phải lúc nào cũng có đủ dung lượng trên /data để tải gói cập nhật xuống. Vì cả OEM và người dùng đều không muốn lãng phí dung lượng trên phân vùng /cache, một số người dùng không nhận được bản cập nhật vì thiết bị không có nơi nào để lưu trữ gói cập nhật. Để giải quyết vấn đề này, Android 8.0 đã thêm tính năng hỗ trợ cho các bản cập nhật A/B truyền trực tuyến, ghi các khối trực tiếp vào phân vùng B khi chúng được tải xuống mà không cần lưu trữ các khối trên /data. Các bản cập nhật A/B truyền trực tuyến hầu như không cần bộ nhớ tạm thời và chỉ cần đủ bộ nhớ cho khoảng 100 KiB siêu dữ liệu.

Để bật tính năng cập nhật truyền trực tuyến trong Android 7.1, hãy chọn các bản vá sau:

Bạn cần có các bản vá này để hỗ trợ truyền trực tuyến các bản cập nhật A/B trong Android 7.1 trở lên, cho dù bạn đang dùng Dịch vụ di động của Google (GMS) hay bất kỳ ứng dụng cập nhật nào khác.

Vòng đời của bản cập nhật A/B

Quá trình cập nhật bắt đầu khi có một gói OTA (trong mã được gọi là tải trọng) để tải xuống. Các chính sách trong thiết bị có thể trì hoãn quá trình tải và áp dụng tải trọng dựa trên mức pin, hoạt động của người dùng, trạng thái sạc hoặc các chính sách khác. Ngoài ra, vì quá trình cập nhật diễn ra ở chế độ nền, nên người dùng có thể không biết rằng quá trình cập nhật đang diễn ra. Tất cả những điều này có nghĩa là quá trình cập nhật có thể bị gián đoạn bất cứ lúc nào do chính sách, việc khởi động lại ngoài ý muốn hoặc hành động của người dùng.

Ngoài ra, siêu dữ liệu trong chính gói OTA cho biết bản cập nhật có thể được truyền trực tuyến; bạn cũng có thể dùng cùng một gói cho quá trình cài đặt không truyền trực tuyến. Máy chủ có thể dùng siêu dữ liệu để cho ứng dụng biết rằng máy chủ đang phát trực tuyến, nhờ đó, ứng dụng sẽ chuyển OTA sang update_engine một cách chính xác. Các nhà sản xuất thiết bị có máy chủ và ứng dụng riêng có thể bật tính năng cập nhật truyền trực tuyến bằng cách đảm bảo máy chủ xác định bản cập nhật đang truyền trực tuyến (hoặc giả định tất cả bản cập nhật đều đang truyền trực tuyến) và ứng dụng đưa ra lệnh gọi chính xác đến update_engine để truyền trực tuyến. Nhà sản xuất có thể sử dụng thực tế là gói này thuộc biến thể phát trực tuyến để gửi một cờ đến ứng dụng nhằm kích hoạt việc chuyển giao cho phía khung dưới dạng phát trực tuyến.

Sau khi có tải trọng, quy trình cập nhật sẽ diễn ra như sau:

Bước Hoạt động
1 Khe hiện tại (hoặc "khe nguồn") được đánh dấu là thành công (nếu chưa được đánh dấu) bằng markBootSuccessful().
2 Khe cắm không dùng đến (hoặc "khe cắm mục tiêu") được đánh dấu là không thể khởi động bằng cách gọi hàm setSlotAsUnbootable(). Vị trí hiện tại luôn được đánh dấu là thành công khi bắt đầu quá trình cập nhật để ngăn trình tải khởi động quay lại vị trí không dùng đến. Vị trí này sẽ sớm có dữ liệu không hợp lệ. Nếu hệ thống đã đạt đến điểm có thể bắt đầu áp dụng một bản cập nhật, thì khe cắm hiện tại sẽ được đánh dấu là thành công ngay cả khi các thành phần chính khác bị hỏng (chẳng hạn như giao diện người dùng trong một vòng lặp sự cố) vì có thể đẩy phần mềm mới để khắc phục những vấn đề này.

Tải trọng cập nhật là một blob mờ có hướng dẫn cập nhật lên phiên bản mới. Phần dữ liệu thực tế của bản cập nhật bao gồm những nội dung sau:
  • Siêu dữ liệu. Siêu dữ liệu là một phần tương đối nhỏ của tải trọng cập nhật, chứa danh sách các thao tác để tạo và xác minh phiên bản mới trên khe mục tiêu. Ví dụ: một thao tác có thể giải nén một blob nhất định và ghi blob đó vào các khối cụ thể trong một phân vùng đích, hoặc đọc từ một phân vùng nguồn, áp dụng một bản vá nhị phân và ghi vào các khối nhất định trong một phân vùng đích.
  • Dữ liệu bổ sung. Là phần lớn tải trọng cập nhật, dữ liệu bổ sung liên kết với các thao tác bao gồm blob nén hoặc bản vá nhị phân trong những ví dụ này.
3 Siêu dữ liệu trọng tải được tải xuống.
4 Đối với mỗi thao tác được xác định trong siêu dữ liệu, theo thứ tự, dữ liệu liên kết (nếu có) sẽ được tải xuống bộ nhớ, thao tác được áp dụng và bộ nhớ liên kết sẽ bị loại bỏ.
5 Toàn bộ phân vùng sẽ được đọc lại và xác minh dựa trên hàm băm dự kiến.
6 Bước sau khi cài đặt (nếu có) sẽ được chạy. Trong trường hợp xảy ra lỗi trong quá trình thực hiện bất kỳ bước nào, quá trình cập nhật sẽ không thành công và được thử lại với một tải trọng có thể khác. Nếu tất cả các bước cho đến nay đều thành công, thì quá trình cập nhật sẽ thành công và bước cuối cùng sẽ được thực hiện.
7 Khe cắm không dùng đến được đánh dấu là đang hoạt động bằng cách gọi setActiveBootSlot(). Việc đánh dấu khe cắm không dùng đến là đang hoạt động không có nghĩa là khe cắm đó sẽ hoàn tất quá trình khởi động. Trình tải khởi động (hoặc chính hệ thống) có thể chuyển đổi lại khe cắm đang hoạt động nếu không đọc được trạng thái thành công.
8 Giai đoạn sau khi cài đặt (được mô tả bên dưới) liên quan đến việc chạy một chương trình từ phiên bản "bản cập nhật mới" trong khi vẫn chạy ở phiên bản cũ. Nếu được xác định trong gói OTA, bước này là bắt buộc và chương trình phải trả về mã thoát 0; nếu không, quá trình cập nhật sẽ không thành công.
9 Sau khi hệ thống khởi động thành công vào khe cắm mới và hoàn tất các bước kiểm tra sau khi khởi động lại, khe cắm hiện tại (trước đây là "khe cắm đích") sẽ được đánh dấu là thành công bằng cách gọi markBootSuccessful().

Sau khi cài đặt

Đối với mỗi phân vùng có xác định một bước sau khi cài đặt, update_engine sẽ gắn phân vùng mới vào một vị trí cụ thể và thực thi chương trình được chỉ định trong OTA tương ứng với phân vùng đã gắn. Ví dụ: nếu chương trình sau khi cài đặt được xác định là usr/bin/postinstall trong phân vùng hệ thống, thì phân vùng này từ khe cắm không dùng đến sẽ được gắn ở một vị trí cố định (chẳng hạn như /postinstall_mount) và lệnh /postinstall_mount/usr/bin/postinstall sẽ được thực thi.

Để quá trình sau khi cài đặt diễn ra thành công, nhân cũ phải có khả năng:

  • Gắn định dạng hệ thống tệp mới. Loại hệ thống tệp không thể thay đổi trừ phi có hỗ trợ cho loại hệ thống tệp đó trong nhân cũ, bao gồm cả các thông tin chi tiết như thuật toán nén được dùng nếu bạn dùng hệ thống tệp nén (tức là SquashFS).
  • Tìm hiểu định dạng chương trình sau khi cài đặt của phân vùng mới. Nếu sử dụng tệp nhị phân Định dạng có thể thực thi và liên kết (ELF), thì tệp này phải tương thích với nhân cũ (ví dụ: một chương trình mới 64 bit chạy trên nhân cũ 32 bit nếu cấu trúc chuyển từ bản dựng 32 bit sang 64 bit). Trừ phi trình tải (ld) được hướng dẫn sử dụng các đường dẫn khác hoặc tạo một tệp nhị phân tĩnh, nếu không, các thư viện sẽ được tải từ hình ảnh hệ thống cũ chứ không phải hình ảnh hệ thống mới.

Ví dụ: bạn có thể dùng một tập lệnh shell làm chương trình sau khi cài đặt do tệp nhị phân shell của hệ thống cũ diễn giải bằng một điểm đánh dấu #! ở trên cùng, sau đó thiết lập đường dẫn thư viện từ môi trường mới để thực thi một chương trình sau khi cài đặt nhị phân phức tạp hơn. Ngoài ra, bạn có thể chạy bước sau khi cài đặt từ một phân vùng nhỏ chuyên dụng để cho phép cập nhật định dạng hệ thống tệp trong phân vùng hệ thống chính mà không gặp phải vấn đề về khả năng tương thích ngược hoặc các bản cập nhật từng bước; điều này sẽ cho phép người dùng cập nhật trực tiếp lên phiên bản mới nhất từ một hình ảnh gốc.

Chương trình sau khi cài đặt mới bị giới hạn bởi các chính sách SELinux được xác định trong hệ thống cũ. Do đó, bước sau khi cài đặt phù hợp để thực hiện các tác vụ bắt buộc theo thiết kế trên một thiết bị nhất định hoặc các tác vụ khác được thực hiện tối ưu nhất có thể. Bước sau khi cài đặt không phù hợp với các bản sửa lỗi một lần trước khi khởi động lại mà yêu cầu các quyền không lường trước được.

Chương trình sau khi cài đặt đã chọn sẽ chạy trong ngữ cảnh postinstall SELinux. Tất cả các tệp trong phân vùng được gắn mới sẽ được gắn thẻ bằng postinstall_file, bất kể thuộc tính của chúng là gì sau khi khởi động lại vào hệ thống mới đó. Những thay đổi đối với các thuộc tính SELinux trong hệ thống mới sẽ không ảnh hưởng đến bước sau khi cài đặt. Nếu chương trình sau khi cài đặt cần có thêm quyền, thì bạn phải thêm các quyền đó vào bối cảnh sau khi cài đặt.

Sau khi khởi động lại

Sau khi khởi động lại, update_verifier sẽ kích hoạt quy trình kiểm tra tính toàn vẹn bằng dm-verity. Quy trình kiểm tra này bắt đầu trước zygote để tránh các dịch vụ Java thực hiện bất kỳ thay đổi không thể đảo ngược nào có thể ngăn chặn việc khôi phục an toàn. Trong quá trình này, trình tải khởi động và nhân cũng có thể kích hoạt quy trình khởi động lại nếu quy trình xác minh quy trình khởi động hoặc dm-verity phát hiện thấy bất kỳ lỗi nào. Sau khi kiểm tra xong, update_verifier sẽ đánh dấu quá trình khởi động thành công.

update_verifier sẽ chỉ đọc các khối được liệt kê trong /data/ota_package/care_map.txt, được đưa vào gói OTA A/B khi sử dụng mã AOSP. Ứng dụng Java cập nhật hệ thống (chẳng hạn như GmsCore) sẽ trích xuất care_map.txt, thiết lập quyền truy cập trước khi khởi động lại thiết bị và xoá tệp đã trích xuất sau khi hệ thống khởi động thành công vào phiên bản mới.