Thêm thiết bị mới

Sử dụng thông tin trên trang này để tạo các tệp makefile cho thiết bị và sản phẩm của bạn.

Mỗi mô-đun Android mới phải có một tệp cấu hình để hướng dẫn hệ thống tạo bản dựng bằng siêu dữ liệu mô-đun, các phần phụ thuộc trong 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. Hãy xem bài viết Tạo Android để biết thêm thông tin về hệ thống xây dựng Android.

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

Hệ thống 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 tạo 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 có mối quan hệ một với nhiều với lớp ở trên. Ví dụ: một cấu 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àm chuyên môn hoá của một phần tử trong cùng lớp. Điều này giúp loại bỏ việc sao chép và đơn giản hoá việc duy trì.

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

Khi tạo bản dựng cho một sản phẩm cụ thể, bạn nên có các biến thể nhỏ trong bản dựng phát hành cuối cùng. Trong một định nghĩa mô-đun, mô-đun có thể chỉ định các thẻ bằng LOCAL_MODULE_TAGS, 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 chỉ định thẻ (bằng LOCAL_MODULE_TAGS), thì thẻ của mô-đun đó sẽ mặc định là optional. Một mô-đun không bắt buộc chỉ được cài đặt nếu cấu hình sản phẩm yêu cầu mô-đun đó bằng PRODUCT_PACKAGES.

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

Nguyên tắc cho userdebug

Việc chạy các bản gỡ lỗi người dùng trong quá trình kiểm thử giúp nhà phát triển thiết bị hiểu được hiệu suất và mức tiêu thụ điện năng 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 bản dựng người dùng và bản dựng userdebug, cũng như để đạ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ị nên tuân theo các nguyên tắc sau:

• userdebug được xác định là bản dựng người dùng đã bật quyền truy cập gốc, ngoại trừ:
  • chỉ những ứng dụng userdebug mà người dùng chỉ chạy theo yêu cầu
  • Các thao tác chỉ chạy trong quá trình bảo trì ở trạng thái không hoạt động (khi đang sạc/sạc đầy), chẳng hạn như sử dụng dex2oatd so với dex2oat để biên dịch trong nền
• Không thêm những tính năng được bật/tắt theo mặc định dựa trên loại bản dựng. 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 ả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 heap.
• Mọi tính năng gỡ lỗi được bật theo mặc định trong userdebug đều phải được xác định rõ ràng và chia sẻ với tất cả nhà phát triển đang làm việc trên dự án. Bạn chỉ nên bật các tính năng gỡ lỗi trong thời gian có hạn cho đến khi vấn đề mà 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 sử 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 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 tệp bản dựng dự án để đặt PRODUCT_PACKAGE_OVERLAYS thành một đường dẫn tương ứng với thư mục cấp cao nhất. Đường dẫn đó sẽ trở thành một 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 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 bản dựng dự án bằng một trong những cách sau:

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

hoặc

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Sau đó, hãy thêm một 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 có trong tệp config.xml lớp phủ sẽ thay thế những chuỗi hoặc mảng chuỗi có 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ị theo nhiều cách. Sau đây là nội dung mô tả ngắn gọn về một cách sắp xếp việc triển khai Pixel.

Pixel được triển khai bằng 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 bằng tệp makefile định nghĩa sản phẩm, trong đó khai báo thông tin dành riêng cho sản phẩm về thiết bị, chẳng hạn như tên và mẫu. Bạn có thể xem thư mục device/google/marlin để biết cách thiết lập tất cả những nội dung này.

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

Các bước sau đây mô tả cách thiết lập tệp make của sản phẩm theo cách tương tự như 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 makefile để tạo mã nguồn.
2. Tạo một tệp device.mk makefile 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.
3. Tạo một tệp 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 đâ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ừ các tệp device/google/marlin/device-marlin.mk và vendor/google/marlin/device-vendor-marlin.mk thông qua tệp makefile, đồng thời khai báo thông tin cụ thể về sản phẩm, chẳng hạn 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
   

   Hãy xem phần Đặt các biến định nghĩa sản phẩm để biết thêm các biến dành riêng cho sản phẩm mà bạn có thể thêm vào tệp makefile.

4. Tạo một tệp AndroidProducts.mk trỏ đến các tệp makefile của sản phẩm. Trong ví dụ này, bạn 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), có chung 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 BoardConfig.mkmakefile 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.
6. Chỉ dành cho Android 9 trở xuống, hãy tạo tệp vendorsetup.sh để thêm sản phẩm (một "bữa trưa kết hợp") 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 thêm các 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 sản phẩm

Các 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 cho thấy một số biến được duy trì trong tệp định nghĩa sản phẩm.

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

Sử dụng thông tin này để định cấu hình bộ lọc 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.

Thuộ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: để đặt ngôn ngữ mặc định. Ban đầu, giá trị 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 các biến định nghĩa sản phẩm.)
• ro.localization.locale_filter: để đặt bộ lọc ngôn ngữ, sử dụng 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 (các biến thể tiếng Đức ở Áo và Đức), tất cả các biến thể tiếng Anh và tiếng Ukraina
  • Bộ lọc loại trừ: ^(?!de-IT|es).* – loại trừ tiếng Đức (biến thể tiếng Ý) và tất cả các biến thể 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 quy tắc hạn chế mà không cần đưa bộ lọc vào ả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 các thuộc tính đó vào biến PRODUCT_OEM_PROPERTIES như minh hoạ 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ế sẽ được ghi vào oem/oem.prop để phản ánh các yêu cầu về mục tiêu. Với phương pháp này, các giá trị mặc định sẽ được giữ lại trong quá trình đặt lại về trạng thái ban đầu, do đó, các chế độ cài đặt ban đầu sẽ trông giống hệt như chế độ thiết lập lần đầu đố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 nhà sản xuất thiết bị truy cập vào 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 uỷ quyền theo cách thủ công. Thông thường, adb sẽ tạo một khoá xác thực RSA duy nhất cho mỗi máy tính khách. Khoá này sẽ được gửi đến mọi thiết bị được kết nối. Đây là khoá RSA xuất hiện trong hộp thoại uỷ quyền adb. Ngoài ra, bạn có thể tạo các khoá đã biết vào hình ảnh hệ thống và chia sẻ chúng với ứng dụng adb. Điều này hữu ích cho quá trình phát triển hệ điều hành và đặc biệt là cho việc kiểm thử vì bạn không cần phải tương tác theo cách thủ công với hộp thoại uỷ quyền adb.

Để tạo khoá 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 khoá bằng cách sử dụng adb keygen. Đối với các thiết bị của Google, Google sẽ tạo một cặp khoá mới cho mỗi phiên bản hệ điều hành mới.
2. Kiểm tra các cặp khoá ở đâu đó trong cây nguồn. Google lưu trữ các thông tin này trong vendor/google/security/adb/, chẳng hạn.
3. Đặt biến bản dựng PRODUCT_ADB_KEYS để trỏ đến thư mục khoá 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 khoá có nội dung PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub. Nội dung này giúp đảm bảo rằng chúng tôi nhớ tạo một cặp khoá mới cho mỗi phiên bản hệ điều hành.

Dưới đâ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 khoá đã đă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 khoá củ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 khoá. Điều này cho phép adb thử các khoá chuẩn này trước, sau đó quay lại khoá máy chủ đã tạo cần có sự cho phép thủ công. Khi adb không thể kết nối với một thiết bị không được phép, thông báo lỗi sẽ đề xuất bạn thiết lập ADB_VENDOR_KEYS nếu chưa thiết lập.