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.

Trang này được dịch bởi Cloud Translation API.

Thêm thiết bị mới

Sử dụng thông tin trong trang này để tạo tệp makefile cho thiết bị của bạn và của Google.

Mỗi mô-đun Android mới phải có một tệp cấu hình để chỉ dẫn hệ thống xây dựng với siêu dữ liệu của mô-đun, phần phụ thuộc thời gian biên dịch và hướng dẫn đóng gói. Android sử dụng Hệ thống xây dựng Soong. Xem phần Xây dựng Android để biết thêm thông tin về Android hệ thống xây dựng.

Tìm hiểu về các lớp bản dựng

Hệ phân cấp bản dựng bao gồm các lớp trừu tượng tương ứng với cấu trúc bề ngoài của một thiết bị. Các lớp này được mô tả trong bảng bên dưới. Mỗi lớp liên quan đến lớp phía trên nó trong mối quan hệ một với nhiều. Cho Ví dụ: một kiến trúc có thể có nhiều bảng và mỗi bảng có thể có nhiều sản phẩm. Bạn có thể xác định một phần tử trong một lớp nhất định là chuyên môn hoá của một phần tử trong cùng một lớp, giúp loại bỏ việc sao chép và giúp đơn giản hoá việc bảo trì.

Lớp	Ví dụ	Mô tả
Sản phẩm	myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk	Lớp sản phẩm xác định quy cách tính năng của thông tin vận chuyển chẳng hạn như mô-đun cần xây dựng, ngôn ngữ được hỗ trợ và cho các ngôn ngữ khác nhau. Nói cách khác, đây là tên của toàn bộ sản phẩm. Các biến theo sản phẩm cụ thể được xác định trong tệp makefile định nghĩa sản phẩm. Một sản phẩm có thể kế thừa từ định nghĩa sản phẩm, giúp đơn giản hoá việc bảo trì. Một phương thức phổ biến là tạo sản phẩm cơ bản có các tính năng áp dụng cho tất cả sản phẩm, rồi tạo các biến thể sản phẩm dựa trên cơ sở đó của Google. Ví dụ: hai sản phẩm chỉ khác nhau về vô tuyến của họ (CDMA so với GSM) có thể kế thừa từ cùng một sản phẩm cơ sở không xác định đài.
Bảng/thiết bị	marlin, xanh dương, san hô	Lớp bo mạch/thiết bị đại diện cho lớp nhựa vật lý trên thiết bị (tức là kiểu dáng công nghiệp của thiết bị). Lớp này cũng thể hiện phần trần sơ đồ của một sản phẩm. Các thiết bị này bao gồm các thiết bị ngoại vi trên bảng và các thiết bị . Tên được dùng chỉ đơn thuần là mã cho các bảng/thiết bị khác nhau .
Vòm	arm, x86, arm64, x86_64	Tầng kiến trúc mô tả cấu hình bộ xử lý và giao diện nhị phân của ứng dụng (ABI) đang chạy trên bảng.

Sử dụng biến thể bản dựng

Khi xây dựng một sản phẩm cụ thể, bạn nên có các nhóm các biến thể của bản phát hành chính thức. Trong mô-đun , mô-đun này có thể chỉ định các thẻ bằng LOCAL_MODULE_TAGS, có thể là một hoặc nhiều giá trị optional (mặc định), debug và eng.

Nếu một mô-đun không chỉ định thẻ (bằng LOCAL_MODULE_TAGS), thì mô-đun đó mặc định của thẻ là optional. Mô-đun không bắt buộc chỉ được cài đặt nếu đây là yêu cầu theo cấu hình sản phẩm với PRODUCT_PACKAGES.

Đây là những biến thể bản dựng hiện được xác định.

Biến thể	Mô tả
`eng`	Đây là hương vị mặc định. Cài đặt các mô-đun được gắn thẻ bằng `eng` hoặc `debug`. Cài đặt các mô-đun theo tệp định nghĩa sản phẩm, trong ngoài các mô-đun được gắn thẻ. `ro.secure=0` `ro.debuggable=1` `ro.kernel.android.checkjni=1` `adb` được bật theo mặc định.
`user`	Biến thể được coi là bit phát hành chính thức. Cài đặt các mô-đun được gắn thẻ bằng `user`. Cài đặt các mô-đun theo tệp định nghĩa sản phẩm, trong ngoài các mô-đun được gắn thẻ. `ro.secure=1` `ro.debuggable=0` `adb` bị tắt theo mặc định.
`userdebug`	Giống như `user`, với các ngoại lệ sau: Đồng thời cài đặt các mô-đun được gắn thẻ bằng `debug`. `ro.debuggable=1` `adb` được bật theo mặc định.

Nguyên tắc gỡ lỗi cho người dùng

Việc chạy bản dựng userdebug trong quá trình kiểm thử sẽ giúp nhà phát triển thiết bị nắm được hiệu suất và sức mạnh của bản phát hành đang trong quá trình phát triển. Để duy trì tính nhất quán giữa các bản dựng userdebug và userdebug, đồng thời đạt được các chỉ số đáng tin cậy trong các bản dựng dùng để gỡ lỗi, nhà phát triển thiết bị phải tuân theo các nguyên tắc sau:

userdebug được định nghĩa là một bản dựng của người dùng đã bật quyền truy cập thư mục gốc, ngoại trừ:
- các ứng dụng chỉ dành cho người dùng gỡ lỗi mà người dùng chỉ chạy theo yêu cầu
- Các hoạt động chỉ chạy trong thời gian bảo trì ở trạng thái rảnh (khi sạc/sử dụng hoàn toàn) tính phí), chẳng hạn như sử dụng dex2oatd so với dex2oat để biên dịch ở chế độ nền
Đừng thêm các tính năng được bật/tắt theo mặc định dựa trên loại bản dựng. Các nhà phát triển không nên sử dụng bất kỳ hình thức ghi nhật ký nào có ảnh hưởng đến thời lượng pin, chẳng hạn như ghi nhật ký gỡ lỗi hoặc kết xuất vùng nhớ khối xếp.
Bạn phải xác định rõ mọi tính năng gỡ lỗi được bật theo mặc định trong tính năng gỡ lỗi cho người dùng và được chia sẻ với tất cả các nhà phát triển đang thực hiện dự án. Bạn nên bật các tính năng gỡ lỗi chỉ trong thời gian có hạn cho đến khi sự cố bạn đang cố gắng gỡ lỗi được giải quyết.

Tuỳ chỉnh bản dựng bằng lớp phủ tài nguyên

Hệ thống xây dựng Android dùng lớp phủ tài nguyên để tuỳ chỉnh một sản phẩm tại thời điểm xây dựng. Lớp phủ tài nguyên chỉ định tài nguyên tệp được áp dụng ngoài các tuỳ chọn mặc định. Để sử dụng lớp phủ tài nguyên, hãy chỉnh sửa dự án buildfile để đặt PRODUCT_PACKAGE_OVERLAYS thành một tương ứng với thư mục cấp cao nhất của bạn. Đường dẫn đó trở thành gốc bóng được tìm kiếm cùng với gốc hiện tại khi hệ thống xây dựng tìm kiếm tài nguyên.

Các chế độ cài đặt thường được tuỳ chỉnh nhất đều có trong tệp frameworks/base/core/res/res/values/config.xml.

Để thiết lập lớp phủ tài nguyên trên tệp này, hãy thêm thư mục lớp phủ vào tệp buildfile của dự án bằng một trong các lệnh sau:

PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay

hoặc

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Sau đó, thêm tệp lớp phủ vào thư mục, ví dụ:

vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml

Mọi chuỗi hoặc mảng chuỗi tìm thấy trong tệp lớp phủ config.xml sẽ thay thế các kết quả tìm thấy trong tệp gốc.

Tạo sản phẩm

Bạn có thể sắp xếp các tệp nguồn cho thiết bị của mình theo nhiều cách. Sau đây là thông tin tóm tắt nội dung mô tả về một cách tổ chức việc triển khai Pixel.

Pixel được triển khai bằng một cấu hình chính của thiết bị có tên là marlin. Từ cấu hình thiết bị này, một sản phẩm được tạo với tệp makefile định nghĩa về sản phẩm khai báo thông tin cụ thể về sản phẩm về thiết bị như tên và kiểu máy. Bạn có thể xem Thư mục device/google/marlin để xem cách thiết lập tất cả những điều này.

Viết tệp makefile cho sản phẩm

Các bước sau đây mô tả cách thiết lập tệp makefile cho sản phẩm theo cách tương tự so với dòng sản phẩm Pixel:

Tạo một device/<company-name>/<device-name> cho thư mục của bạn của Google. Ví dụ: device/google/marlin. Thư mục này sẽ chứa mã nguồn cho thiết bị của bạn cùng với các tệp makefile để tạo chúng.
Tạo một tệp makefile device.mk khai báo các tệp và mô-đun cần thiết cho thiết bị. Để biết ví dụ, hãy xem device/google/marlin/device-marlin.mk.
Tạo tệp makefile định nghĩa về sản phẩm để tạo một sản phẩm cụ thể dựa trên thiết bị. Chiến lược phát hành đĩa đơn makefile sau đây được lấy từ device/google/marlin/aosp_marlin.mk làm ví dụ. Lưu ý rằng sản phẩm kế thừa từ device/google/marlin/device-marlin.mk và vendor/google/marlin/device-vendor-marlin.mk tệp thông qua tệp makefile trong khi đồng thời khai báo thông tin cụ thể về sản phẩm như tên, thương hiệu và kiểu máy.
```
# Inherit from the common Open Source product configuration
$(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk)

PRODUCT_NAME := aosp_marlin
PRODUCT_DEVICE := marlin
PRODUCT_BRAND := Android
PRODUCT_MODEL := AOSP on msm8996
PRODUCT_MANUFACTURER := Google
PRODUCT_RESTRICT_VENDOR_FILES := true

PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin

$(call inherit-product, device/google/marlin/device-marlin.mk)
$(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk)

PRODUCT_PACKAGES += \
    Launcher3QuickStep \
    WallpaperPicker
```
Xem bài viết Đặt biến định nghĩa sản phẩm để biết thêm biến dành riêng cho sản phẩm mà bạn có thể thêm vào tệp makefile của mình.
Tạo một tệp AndroidProducts.mk trỏ đến tệp makefile của sản phẩm. Trong trong ví dụ này, chỉ cần tệp makefile định nghĩa sản phẩm. Ví dụ bên dưới là từ device/google/marlin/AndroidProducts.mk (chứa cả marlin, Pixel, và sailfish, Pixel XL (dùng chung hầu hết các cấu hình):
```
PRODUCT_MAKEFILES := \
	$(LOCAL_DIR)/aosp_marlin.mk \
	$(LOCAL_DIR)/aosp_sailfish.mk

COMMON_LUNCH_CHOICES := \
	aosp_marlin-userdebug \
	aosp_sailfish-userdebug
```
Tạo một tệp makefile BoardConfig.mk chứa các cấu hình dành riêng cho bảng. Để biết ví dụ, hãy xem device/google/marlin/BoardConfig.mk.
Chỉ dành cho Android 9 trở xuống, hãy tạo một Tệp vendorsetup.sh để thêm sản phẩm của bạn ("kết hợp bữa trưa") vào bản dựng cùng với biến thể bản dựng được phân tách bằng một dấu gạch ngang. Ví dụ:
```
add_lunch_combo <product-name>-userdebug
```
Đến đây, bạn có thể tạo thêm nhiều biến thể sản phẩm dựa trên cùng một thiết bị.

Đặt các biến định nghĩa về sản phẩm

Biến dành riêng cho sản phẩm được xác định trong tệp makefile của sản phẩm. Bảng này hiển thị một số các biến được duy trì trong tệp định nghĩa sản phẩm.

Biến	Mô tả	Ví dụ
`PRODUCT_AAPT_CONFIG`	Các cấu hình `aapt` để sử dụng khi tạo gói.
`PRODUCT_BRAND`	Thương hiệu (ví dụ: nhà mạng) mà phần mềm được tùy chỉnh.
`PRODUCT_CHARACTERISTICS`	Các đặc điểm `aapt` để cho phép thêm tài nguyên dành riêng cho biến thể vào gói.	`tablet`, `nosdcard`
`PRODUCT_COPY_FILES`	Danh sách các từ như `source_path:destination_path`. Tệp tại đường dẫn nguồn phải được sao chép sang đường dẫn đích khi tạo sản phẩm này. Quy tắc cho bản sao bước được xác định trong `config/makefile`.
`PRODUCT_DEVICE`	Tên kiểu dáng công nghiệp. Đây cũng là tên bảng và hệ thống xây dựng sử dụng tên này để xác định vị trí `BoardConfig.mk`.	`tuna`
`PRODUCT_LOCALES`	Danh sách mã ngôn ngữ gồm hai chữ cái được phân tách bằng dấu cách, các cặp mã quốc gia gồm hai chữ cái mô tả một số chế độ cài đặt cho người dùng, chẳng hạn như ngôn ngữ và giờ trên giao diện người dùng, ngày tháng và định dạng đơn vị tiền tệ. Ngôn ngữ đầu tiên được liệt kê trong `PRODUCT_LOCALES` được dùng làm ngôn ngữ mặc định của sản phẩm.	`en_GB`, `de_DE`, `es_ES`, `fr_CA`
`PRODUCT_MANUFACTURER`	Tên nhà sản xuất.	`acme`
`PRODUCT_MODEL`	Tên hiển thị cho người dùng cuối của sản phẩm cuối.
`PRODUCT_NAME`	Tên hiển thị cho người dùng cuối của sản phẩm tổng thể. Xuất hiện trong phần Cài đặt > Màn hình "About (Giới thiệu).
`PRODUCT_OTA_PUBLIC_KEYS`	Danh sách khoá công khai qua mạng không dây (OTA) cho sản phẩm.
`PRODUCT_PACKAGES`	Danh sách tệp APK và mô-đun sẽ cài đặt.	Danh bạ trên Lịch
`PRODUCT_PACKAGE_OVERLAYS`	Cho biết liệu sử dụng tài nguyên mặc định hay thêm lớp phủ dành riêng cho sản phẩm.	`vendor/acme/overlay`
`PRODUCT_SYSTEM_PROPERTIES`	Danh sách chỉ định thuộc tính hệ thống theo định dạng `"key=value"` cho phân vùng hệ thống. Thuộc tính hệ thống cho các phân vùng khác có thể được đặt thông `PRODUCT_<PARTITION>_PROPERTIES` như trong `PRODUCT_VENDOR_PROPERTIES` cho phân vùng nhà cung cấp. Phân vùng được hỗ trợ tên: `SYSTEM`, `VENDOR`, `ODM`, `SYSTEM_EXT` và `PRODUCT`.

Định cấu hình bộ lọc ngôn ngữ và ngôn ngữ mặc định của hệ thống

Dùng thông tin này để định cấu hình bộ lọc ngôn ngữ mặc định và ngôn ngữ của hệ thống, sau đó bật bộ lọc ngôn ngữ cho một loại thiết bị mới.

Thuộc tính

Định cấu hình cả ngôn ngữ mặc định và bộ lọc ngôn ngữ của hệ thống bằng hệ thống chuyên dụng thuộc tính:

ro.product.locale: để đặt ngôn ngữ mặc định. Ban đầu, lựa chọn này được đặt thành ngôn ngữ trong biến PRODUCT_LOCALES; bạn có thể ghi đè giá trị đó. (Để biết thêm thông tin, hãy xem Đặt bảng biến định nghĩa sản phẩm.)
ro.localization.locale_filter: để đặt bộ lọc ngôn ngữ, sử dụng một biểu thức chính quy được áp dụng cho tên ngôn ngữ. Ví dụ:
- Bộ lọc bao gồm: ^(de-AT|de-DE|en|uk).* – chỉ cho phép tiếng Đức (Áo và Đức biến thể), tất cả biến thể tiếng Anh của tiếng Anh và tiếng Ukraina
- Bộ lọc độc quyền: ^(?!de-IT|es).* – không bao gồm tiếng Đức (biến thể của Ý) và tất cả các biến thể của tiếng Tây Ban Nha.

Bật bộ lọc ngôn ngữ

Để bật bộ lọc, hãy thiết lập giá trị chuỗi thuộc tính hệ thống ro.localization.locale_filter.

Bằng cách đặt giá trị thuộc tính bộ lọc và ngôn ngữ mặc định thông qua oem/oem.prop trong thời gian hiệu chỉnh ban đầu, bạn có thể định cấu hình các hạn chế mà không cần áp dụng bộ lọc vào hình ảnh hệ thống. Bạn đảm bảo rằng các thuộc tính này được lấy từ phân vùng OEM bằng cách thêm chúng vào Biến PRODUCT_OEM_PROPERTIES như trình bày dưới đây:

# Delegation for OEM customization
PRODUCT_OEM_PROPERTIES += \
    ro.product.locale \
    ro.localization.locale_filter

Sau đó, trong quá trình sản xuất, các giá trị thực tế được ghi vào oem/oem.prop để phản ánh mục tiêu các yêu cầu liên quan. Với phương pháp này, giá trị mặc định được giữ lại trong quá trình đặt lại về trạng thái ban đầu, do đó cài đặt ban đầu giống hệt như thiết lập đầu tiên đối với người dùng.

Đặt ADB_Ask_KEYS để kết nối qua USB

Biến môi trường ADB_VENDOR_KEYS cho phép nhà sản xuất thiết bị truy cập các bản dựng có thể gỡ lỗi (-userdebug và -eng, nhưng không phải -user) qua adb mà không được ủy quyền thủ công. Thông thường, adb tạo một khoá xác thực RSA duy nhất cho mỗi máy khách. Khoá này sẽ gửi với bất kỳ thiết bị nào được kết nối. Đây là khoá RSA hiển thị trong hộp thoại uỷ quyền adb. Là một thay vào đó, bạn có thể tạo các khoá đã biết vào hình ảnh hệ thống rồi chia sẻ các khoá đó với ứng dụng adb. Điều này rất hữu ích cho việc phát triển hệ điều hành, đặc biệt là cho việc kiểm thử vì giúp tránh việc tương tác với hộp thoại uỷ quyền adb.

Để tạo khoá của nhà cung cấp, một người (thường là người quản lý phát hành) cần:

Tạo một cặp khoá bằng adb keygen. Đối với các thiết bị Google, Google tạo một cho từng phiên bản hệ điều hành mới.
Kiểm tra các cặp khoá ở một nơi nào đó trong cây nguồn. Google lưu trữ chúng trong vendor/google/security/adb/.
Đặt biến bản dựng PRODUCT_ADB_KEYS để trỏ đến thư mục chính của bạn. Google thực hiện việc này bằng cách thêm một tệp Android.mk vào thư mục chính có nội dung PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub, giúp đảm bảo rằng chúng tôi sẽ tạo một cặp khoá mới cho mỗi phiên bản hệ điều hành.

Đây là tệp makefile mà Google sử dụng trong thư mục nơi chúng tôi lưu trữ các cặp khoá đã đăng ký cho mỗi phát hành:

PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub

ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),)
  $(warning ========================)
  $(warning The adb key for this release)
  $(warning )
  $(warning   $(PRODUCT_ADB_KEYS))
  $(warning )
  $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk)
  $(warning has changed and a new adb key needs to be generated.)
  $(warning )
  $(warning Please run the following commands to create a new key:)
  $(warning )
  $(warning   make -j8 adb)
  $(warning   LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS)))
  $(warning )
  $(warning and upload/review/submit the changes)
  $(warning ========================)
  $(error done)
endif

Để sử dụng các khoá của nhà cung cấp này, kỹ sư chỉ cần đặt ADB_VENDOR_KEYS biến môi trường để trỏ đến thư mục lưu trữ cặp khoá. Thao tác này sẽ yêu cầu adb thử các khoá chính tắc này trước, trước khi quay lại khoá đã tạo khoá máy chủ yêu cầu cấp quyền thủ công. Khi adb không thể kết nối với mạng không được cấp phép thiết bị, thông báo lỗi sẽ đề xuất bạn đặt ADB_VENDOR_KEYS nếu đã được đặt.