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.

Thêm thiết bị mới

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.
  • Module cài đặt tagged with eng hoặc debug .
  • Cài đặt các mô-đun theo các tệp định nghĩa sản phẩm, ngoài các mô-đun được gắn thẻ.
  • ro.secure=0
  • ro.debuggable=1
  • ro.kernel.android.checkjni=1
  • adb được kích hoạt theo mặc định.
user Biến thể dự định là các bit phát hành cuối cùng.
  • Module cài đặt được gắn thẻ với user .
  • Cài đặt các mô-đun theo các tệp định nghĩa sản phẩm, 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 những trường hợp ngoại lệ:
  • Cũng cài đặt các module được gắn thẻ với debug .
  • ro.debuggable=1
  • adb được kích hoạt theo mặc định.

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 so dex2oat 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:

  1. 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.
  2. 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ụ, xem device/google/marlin/device-marlin.mk .
  3. 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.mkvendor/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.

  4. 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
    
  5. 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ụ, xem device/google/marlin/BoardConfig.mk .
  6. Đố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
    
  7. 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 trong PRODUCT_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ậ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:

  1. 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.
  2. 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ụ.
  3. Đặ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ột Android.mk tập tin trong thư mục quan trọng mà nói PRODUCT_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.