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 hệ thống xây dựng Soong . Xem Xây dựng 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ự mô 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 định nghĩa mô-đun, mô-đun có thể chỉ định các thẻ với LOCAL_MODULE_TAGS , có thể là một hoặc nhiều giá trị optional (mặc định), debugeng .

Nếu một mô-đun không chỉ định thẻ (bởi LOCAL_MODULE_TAGS ), thì thẻ của nó sẽ mặc định là optional . Mô-đun tùy chọn chỉ được cài đặt nếu cấu hình sản phẩm yêu cầu 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ự mô tả
eng Đây là hương vị mặc định.
  • Cài đặt các mô-đun được gắn thẻ 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 bật theo mặc định.
user Biến thể dự định là các bit phát hành cuối cùng.
  • Cài đặt các mô-đun được gắn thẻ 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 ngoại lệ sau:
  • Cũng cài đặt các mô-đun được gắn thẻ debug .
  • ro.debuggable=1
  • adb được bậ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
    • Các hoạt động chỉ chạy trong thời gian bảo trì không hoạt động (trên bộ sạc / được sạc đầy), chẳng hạn như sử dụng dex2oatd so với dex2oat cho các 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, hãy sửa đổi cấu hình dự án để đặt PRODUCT_PACKAGE_OVERLAYS thành một đường dẫn liên quan đế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 cài đặt tùy chỉnh phổ biến nhất được chứa trong các khung tệp / 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 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 nào được tìm thấy trong tệp overlay config.xml sẽ thay thế những chuỗi hoặc mảng được tìm thấy trong tệp 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 cấu hình thiết bị chính 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 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 thư mục device/google/marlin để xem tất cả những thứ này được thiết lập như thế nào.

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 thư mục device/ <company-name> / <device-name> 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 makefile device.mk khai báo các tệp và mô-đun cần thiết cho thiết bị. Ví dụ: hãy 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ị. Makefile sau đượ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ừ các tệp device/google/marlin/device-marlin.mkvendor/google/marlin/device-vendor-marlin.mk thông qua makefile đồng thời khai báo thông tin cụ thể về sản phẩm 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 Đặt biến định nghĩa sản phẩm để biết các biến bổ sung dành riêng cho sản phẩm mà bạn có thể thêm vào trang điểm của mình.

  4. Tạo tệp AndroidProducts.mk trỏ đến cấu hình của sản phẩm. Trong ví dụ này, chỉ cần 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à cá buồm, Pixel XL, chia sẻ hầu hết 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
    
  5. Tạo một tệp makefile BoardConfig.mk chứa các cấu hình dành riêng cho bảng. Ví dụ: hãy xem device/google/marlin/BoardConfig.mk .
  6. Chỉ dành cho Android 9 trở xuống , hãy tạo tệp vendorsetup.sh để thêm sản phẩm của bạn ("combo ăn trưa") vào bản dựng cùng với một biến thể bản dựng được phân tách bằng 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ự mô tả Thí dụ
PRODUCT_AAPT_CONFIG cấu hình aapt để sử dụng khi tạo 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 đặc điểm aapt để cho phép thêm các tài nguyên dành riêng cho biến thể vào một gói. tablet , nosdcard
PRODUCT_COPY_FILES Danh sách các từ như 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 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 nó để định vị 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ệ. Ngôn ngữ đầu tiên được liệt kê trong PRODUCT_LOCALES được sử 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 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 màn hình Cài đặt> Giới thiệu .
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ài đặt. Lịch liên hệ
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 phép gán thuộc tính hệ thống ở đị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 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_EXTPRODUCT .

Đị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.

Đặc tính

Đị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 ngôn ngữ mặc định. Ban đầu, điều này được đặt thành ngôn ngữ đầu tiên trong biến PRODUCT_LOCALES ; bạn có thể ghi đè giá trị đó. (Để biết thêm thông tin, hãy xem bảng Đặt biến định nghĩa sản phẩm .)
  • ro.localization.locale_filter : để thiết lập bộ lọc ngôn ngữ, sử dụng biểu thức chính quy á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 (các biến thể của Áo và Đức), tất cả cá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).* - loại trừ tiếng Đức (biến thể Ý) 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 đặt 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 quá trình hiệu chuẩn tại nhà máy, bạn có thể định cấu hình các hạn chế mà không cần đưa 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 chọn từ phân vùng OEM bằng cách thêm chúng vào biến PRODUCT_OEM_PROPERTIES như được chỉ ra bên dưới:

# 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 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

Biến môi trường ADB_VENDOR_KEYS cho phép các 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ần ủy quyền thủ công. 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 một cặp khóa bằng cách 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. Ví dụ: Google lưu trữ chúng trong vendor/google/security/adb/ .
  3. Đặ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 điều này bằng cách thêm tệp Android.mk vào thư mục khóa 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 nhớ tạo 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 khóa nhà cung cấp này, kỹ sư chỉ cần đặt biến môi trường ADB_VENDOR_KEYS trỏ đến thư mục lưu trữ các cặp khóa. Điều này yêu cầu adb thử các khóa chuẩn này trước, trước khi quay lại khóa máy chủ đã tạo yêu cầu ủy quyền thủ công. Khi adb không thể kết nối với thiết bị trái phép, thông báo lỗi sẽ đề xuất rằng bạn đặt ADB_VENDOR_KEYS nếu nó chưa được đặt.