Sử dụng thông tin trong trang này để tạo cấu hình cho thiết bị và sản phẩm của bạn.
Mỗi mô-đun Android mới phải có tệp cấu hình để chỉ đạo hệ thống xây dựng với siêu dữ liệu mô-đun, phụ thuộc thời gian biên dịch và hướng dẫn đóng gói. Android sử dụng xây dựng hệ thống Soong . Xem Building Android để biết thêm thông tin về hệ thống xây dựng Android.
Hiểu các lớp xây dựng
Hệ thống phân cấp xây dựng bao gồm các lớp trừu tượng tương ứng với cấu trúc vật lý của một thiết bị. Các lớp này được mô tả trong bảng dưới đây. Mỗi lớp liên quan đến lớp bên trên nó trong mối quan hệ một-nhiều. Ví dụ, một công trình kiến trúc có thể có nhiều hơn một bảng và mỗi bảng có thể có nhiều hơn một sản phẩm. Bạn có thể xác định một phần tử trong một lớp nhất định dưới dạng chuyên môn hóa 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à đơn giản hóa việc bảo trì.
Lớp | Thí dụ | Sự miêu tả |
---|---|---|
Sản phẩm | myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk | Lớp sản phẩm xác định đặc điểm kỹ thuật của sản phẩm vận chuyển, chẳng hạn như các mô-đun để xây dựng, các ngôn ngữ được hỗ trợ và cấu hình cho các ngôn ngữ khác nhau. Nói cách khác, đây là tên của sản phẩm tổng thể. Các biến cụ thể của sản phẩm được xác định trong cấu hình định nghĩa sản phẩm. Một sản phẩm có thể kế thừa từ các định nghĩa sản phẩm khác, điều này giúp đơn giản hóa việc bảo trì. Phương pháp phổ biến là tạo sản phẩm cơ sở chứa các tính năng áp dụng cho tất cả các sản phẩm, sau đó tạo các biến thể sản phẩm dựa trên sản phẩm cơ sở đó. Ví dụ: hai sản phẩm chỉ khác nhau về bộ đàm (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 bộ đàm. |
Bo mạch / thiết bị | marlin, blueline, san hô | Bo mạch / lớp thiết bị đại diện cho lớp nhựa vật lý trên thiết bị (nghĩa là kiểu dáng công nghiệp của thiết bị). Lớp này cũng đại diện cho các sơ đồ trần của một sản phẩm. Chúng bao gồm các thiết bị ngoại vi trên bo mạch và cấu hình của chúng. Các tên được sử dụng chỉ là mã cho các cấu hình bo mạch / thiết bị khác nhau. |
Vòm | arm, x86, arm64, x86_64 | Lớp kiến trúc mô tả cấu hình bộ xử lý và giao diện nhị phân ứng dụng (ABI) đang chạy trên bo mạch. |
Sử dụng các biến thể bản dựng
Khi xây dựng cho một sản phẩm cụ thể, sẽ rất hữu ích nếu có những thay đổi nhỏ trên bản dựng phát hành cuối cùng. Trong một định nghĩa mô-đun, các mô-đun có thể chỉ định thẻ với LOCAL_MODULE_TAGS
, mà có thể là một hoặc nhiều giá trị của optional
(mặc định), debug
, và eng
.
Nếu một mô-đun không xác định một từ khóa (bởi LOCAL_MODULE_TAGS
), giá trị mặc định thẻ của mình để optional
. Một mô-đun tùy chọn được cài đặt chỉ nếu nó yêu cầu cấu hình sản phẩm với PRODUCT_PACKAGES
.
Đây là các biến thể xây dựng hiện được xác định.
Khác nhau | Sự miêu tả |
---|---|
eng | Đây là hương vị mặc định.
|
user | Biến thể dự định là các bit phát hành cuối cùng.
|
userdebug | Giống như user , với những trường hợp ngoại lệ:
|
Nguyên tắc cho userdebug
Việc chạy các bản dựng userdebug trong quá trình thử nghiệm giúp các nhà phát triển thiết bị hiểu được hiệu suất và sức mạnh của các 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 người dùng và người dùng gỡ lỗi bản dựng và để đạt được chỉ số đáng tin cậy trong các bản dựng được sử dụng để gỡ lỗi, các nhà phát triển thiết bị nên 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 với quyền truy cập root được bật, ngoại trừ:
- ứng dụng chỉ dành cho userdebug chỉ được người dùng chạy theo yêu cầu
- Hoạt động mà chỉ chạy trong bảo trì nhàn rỗi (trên bộ sạc / sạc đầy), chẳng hạn như sử dụng
dex2oatd
sodex2oat
cho biên dịch nền
- Không bao gồ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 khuyến khích sử dụng bất kỳ hình thức ghi nhật ký nào ảnh hưởng đến tuổi thọ pin, chẳng hạn như ghi nhật ký gỡ lỗi hoặc kết xuất đống.
- Bất kỳ tính năng gỡ lỗi nào được bật theo mặc định trong userdebug phải được xác định rõ ràng và chia sẻ với tất cả các nhà phát triển đang làm việc trong dự án. Bạn chỉ nên bật các tính năng gỡ lỗi trong thời gian giới hạn cho đến khi vấn đề bạn đang cố gắng gỡ lỗi được giải quyết.
Tùy chỉnh bản dựng với lớp phủ tài nguyên
Hệ thống xây dựng Android sử dụng lớp phủ tài nguyên để tùy chỉnh sản phẩm tại thời điểm xây dựng. Lớp phủ tài nguyên chỉ định các tệp tài nguyên được áp dụng trên các giá trị mặc định. Để sử dụng lớp phủ tài nguyên, sửa đổi buildfile dự án để thiết lập PRODUCT_PACKAGE_OVERLAYS
đến một đường dẫn tương đối đến thư mục cấp cao nhất của bạn. Đường dẫn đó trở thành một gốc bóng tối đượ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 thiết lập tùy chỉnh phổ biến nhất được chứa trong tập tin khuôn khổ / cơ sở / lõi / 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 xây dựng dự án bằng cách sử dụng một trong các cách 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
Bất kỳ chuỗi hoặc mảng chuỗi tìm thấy trong lớp phủ config.xml
tập tin thay thế những mặt hàng trong các tập tin gốc.
Xây dựng một 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 khác nhau. Dưới đây là mô tả ngắn gọn về một cách để tổ chức triển khai Pixel.
Pixel được thực hiện với một chính cấu hình thiết bị tên marlin
. Từ cấu hình thiết bị này, một sản phẩm được tạo với cấu hình định nghĩa sản phẩm khai báo thông tin cụ thể của sản phẩm về thiết bị như tên và kiểu máy. Bạn có thể xem các device/google/marlin
thư mục để xem làm thế nào tất cả điều này được thiết lập.
Viết hồ sơ sản phẩm
Các bước sau đây mô tả cách thiết lập cấu hình sản phẩm theo cách tương tự như của dòng sản phẩm Pixel:
- Tạo một
device/ <company-name> / <device-name>
thư mục cho sản phẩm của bạn. Ví dụ,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 trang điểm để xây dựng chúng. - Tạo một
device.mk
makefile rằng tuyên bố các tập tin và các module cần thiết cho thiết bị. Đối với một ví dụ, xemdevice/google/marlin/device-marlin.mk
. - Tạo một makefile định nghĩa sản phẩm để tạo một sản phẩm cụ thể dựa trên thiết bị. Các makefile sau đây được lấy từ
device/google/marlin/aosp_marlin.mk
làm ví dụ. Chú ý rằng kế thừa sản phẩm từdevice/google/marlin/device-marlin.mk
vàvendor/google/marlin/device-vendor-marlin.mk
tập tin thông qua các makefile đồng thời cũng tuyên bố các thông tin sản phẩm cụ thể như tên, thương hiệu, và mô hình.# 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 Thiết biến định nghĩa sản phẩm cho các biến sản phẩm cụ thể bổ sung mà bạn có thể thêm vào makefiles của bạn.
- Tạo một
AndroidProducts.mk
tập tin trỏ đến makefiles của sản phẩm. Trong ví dụ này, chỉ cần makefile định nghĩa sản phẩm. Ví dụ dưới đây là từdevice/google/marlin/AndroidProducts.mk
(trong đó có cả marlin, Pixel, và cá cờ, các Pixel XL, mà chia sẻ cấu hình nhất):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
BoardConfig.mk
makefile có chứa các cấu hình ban cụ thể. Đối với một ví dụ, xemdevice/google/marlin/BoardConfig.mk
. - Đối với Android 9 và chỉ thấp hơn, tạo ra một
vendorsetup.sh
tập tin để thêm sản phẩm của bạn (một "bữa ăn trưa kết hợp") để xây dựng cùng với một xây dựng biến thể cách nhau bởi một dấu gạch ngang. Ví dụ:add_lunch_combo <product-name>-userdebug
- Tại thời điểm này, bạn có thể tạo nhiều biến thể sản phẩm hơn dựa trên cùng một thiết bị.
Đặt các biến định nghĩa sản phẩm
Các biến dành riêng cho sản phẩm được xác định trong makefile của sản phẩm. Bảng hiển thị một số biến được duy trì trong tệp định nghĩa sản phẩm.
Biến đổi | Sự miêu tả | Thí dụ |
---|---|---|
PRODUCT_AAPT_CONFIG | aapt cấu hình để sử dụng khi tạo các gói. | |
PRODUCT_BRAND | Thương hiệu (ví dụ: nhà cung cấp dịch vụ) mà phần mềm được tùy chỉnh, nếu có. | |
PRODUCT_CHARACTERISTICS | aapt đặc điểm cho phép bổ sung thêm nguồn lực biến thể cụ thể để một gói. | tablet , nosdcard |
PRODUCT_COPY_FILES | Danh sách các từ thích source_path:destination_path . Tệp ở đường dẫn nguồn phải được sao chép vào đường dẫn đích khi xây dựng sản phẩm này. Các quy tắc cho các bước sao chép được quy đị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à xây dựng hệ thống sử dụng nó để xác định vị trí BoardConfig.mk . | tuna |
PRODUCT_LOCALES | Một danh sách được phân tách bằng dấu cách gồm mã ngôn ngữ hai chữ cái, các cặp mã quốc gia hai chữ cái mô tả một số cài đặt cho người dùng, chẳng hạn như ngôn ngữ giao diện người dùng và định dạng thời gian, ngày tháng và tiền tệ. Nơi đặt đầu tiên được liệt kê trong PRODUCT_LOCALES được sử dụng như locale mặc định của sản phẩm. | en_GB , de_DE , es_ES , fr_CA |
PRODUCT_MANUFACTURER | Tên của nhà sản xuất. | acme |
PRODUCT_MODEL | Tên người dùng cuối hiển thị cho sản phẩm cuối cùng. | |
PRODUCT_NAME | Tên người dùng cuối hiển thị cho sản phẩm tổng thể. Xuất hiện trong Cài đặt> Giới thiệu về màn hình. | |
PRODUCT_OTA_PUBLIC_KEYS | Danh sách các khóa công khai qua mạng (OTA) cho sản phẩm. | |
PRODUCT_PACKAGES | Danh sách các APK và mô-đun cần cài đặt. | Danh bạ lịch |
PRODUCT_PACKAGE_OVERLAYS | Cho biết có sử dụng tài nguyên mặc định hay thêm bất kỳ lớp phủ cụ thể nào của sản phẩm hay không. | vendor/acme/overlay |
PRODUCT_SYSTEM_PROPERTIES | Danh sách các bài tập hữu hệ thống theo định dạng "key=value" cho phân vùng hệ thống. Hệ thống thuộc tính cho phân vùng khác có thể được thiết lập thông qua PRODUCT_<PARTITION>_PROPERTIES như trong PRODUCT_VENDOR_PROPERTIES cho phân vùng nhà cung cấp. Tên phân vùng được hỗ trợ: SYSTEM , VENDOR , ODM , SYSTEM_EXT , và PRODUCT . |
Định cấu hình bộ lọc ngôn ngữ và ngôn ngữ hệ thống mặc định
Sử dụng thông tin này để định cấu hình ngôn ngữ mặc định và bộ lọc ngôn ngữ hệ thống, sau đó bật bộ lọc ngôn ngữ cho một loại thiết bị mới.
Tính chất
Định cấu hình cả ngôn ngữ mặc định và bộ lọc ngôn ngữ hệ thống bằng cách sử dụng các thuộc tính hệ thống chuyên dụng:
-
ro.product.locale
: để thiết lập miền địa phương mặc định. Này ban đầu được thiết lập để các địa phương đầu tiên trongPRODUCT_LOCALES
biến; bạn có thể ghi đè giá trị đó. (Để biết thêm thông tin, vui lòng xem sản phẩm Setting biến định nghĩa bảng.) -
ro.localization.locale_filter
: để thiết lập một bộ lọc địa phương, sử dụng một biểu thức chính quy áp dụng đối với ngôn ngữ tên. Ví dụ:- Bộ lọc bao gồm:
^(de-AT|de-DE|en|uk).*
- chỉ cho phép Đức (Áo và Đức biến thể), tất cả các biến thể tiếng Anh của tiếng Anh, và tiếng Ukraina - Lọc độc quyền:
^(?!de-IT|es).*
- không bao gồm Đức (Ý biến thể), và tất cả các biến thể của Tây Ban Nha.
- Bộ lọc bao gồm:
Bật bộ lọc ngôn ngữ
Để kích hoạt bộ lọc, thiết lập ro.localization.locale_filter
hệ thống chuỗi giá trị tài sản.
Bằng cách thiết lập giá trị tài sản và bộ lọc ngôn ngữ mặc định thông qua oem/oem.prop
trong hiệu chuẩn máy bạn có thể cấu hình hạn chế mà không cần nướng bộ lọc vào hình ảnh hệ thống. Bạn chắc chắn rằng các đặc tính này được nhặt từ các phân vùng OEM bằng cách thêm chúng vào PRODUCT_OEM_PROPERTIES
biến như được chỉ ra dưới đây:
# Delegation for OEM customization PRODUCT_OEM_PROPERTIES += \ ro.product.locale \ ro.localization.locale_filter
Sau đó, trong sản xuất giá trị thực tế được ghi vào oem/oem.prop
, để phản ánh các yêu cầu mục tiêu. Với cách tiếp cận này, các giá trị mặc định được giữ lại trong quá trình khôi phục cài đặt gốc, vì vậy cài đặt ban đầu trông giống hệt như thiết lập đầu tiên đối với người dùng.
Đặt ADB_VENDOR_KEYS để kết nối qua USB
Các ADB_VENDOR_KEYS
biến môi trường cho phép các nhà sản xuất thiết bị để truy cập debuggable xây dựng (-userdebug và -eng, nhưng không -user) qua adb mà không được phép bằng tay. Thông thường adb tạo một khóa xác thực RSA duy nhất cho mỗi máy khách, khóa này sẽ gửi đến bất kỳ thiết bị được kết nối nào. Đây là khóa RSA được hiển thị trong hộp thoại ủy quyền adb. Thay vào đó, bạn có thể xây dựng các khóa đã biết vào hình ảnh hệ thống và chia sẻ chúng với ứng dụng khách adb. Điều này rất hữu ích cho việc phát triển hệ điều hành và đặc biệt là để thử nghiệm vì nó tránh được sự cần thiết phải tương tác thủ công với hộp thoại ủy quyền adb.
Để tạo khóa nhà cung cấp, một người (thường là người quản lý phát hành) nên:
- Tạo ra một cặp khóa sử dụng
adb keygen
. Đối với các thiết bị của Google, Google tạo một cặp khóa mới cho mỗi phiên bản hệ điều hành mới. - Kiểm tra các cặp khóa ở đâu đó trong cây nguồn. Google sẽ lưu trữ chúng trong
vendor/google/security/adb/
, ví dụ. - Đặt build biến
PRODUCT_ADB_KEYS
để trỏ đến thư mục chính của bạn. Google thực hiện điều này bằng cách thêm mộtAndroid.mk
tập tin trong thư mục quan trọng mà nóiPRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub
, giúp đảm bảo rằng chúng ta nhớ để tạo ra một cặp khóa mới cho mỗi phiên bản hệ điều hành.
Đây là makefile mà Google sử dụng trong thư mục nơi chúng tôi lưu trữ các cặp khóa đã đăng ký cho mỗi bản 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 phím nhà cung cấp, một kỹ sư chỉ cần thiết lập các ADB_VENDOR_KEYS
biến môi trường để trỏ đến thư mục trong đó các cặp khóa được lưu trữ. Điều này cho adb
để thử các phím kinh điển đầu tiên, trước khi giảm trở lại host key được tạo ra mà đòi hỏi của nhãn hiệu cho phép. Khi adb
không thể kết nối với một thiết bị trái phép, thông báo lỗi sẽ đề nghị bạn nên thiết lập ADB_VENDOR_KEYS
nếu nó chưa được thiết lập.