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.

Hệ thống xây dựng Soong

Trước khi phát hành Android 7.0, Android chỉ sử dụng GNU Make để mô tả và thực thi các quy tắc xây dựng của nó. Hệ thống Make build được hỗ trợ và sử dụng rộng rãi, nhưng ở quy mô của Android trở nên chậm, dễ bị lỗi, không thể mở rộng và khó kiểm tra. Hệ thống bản dựng Soong cung cấp tính linh hoạt cần thiết cho các bản dựng Android.

Vì lý do này, các nhà phát triển nền tảng dự kiến sẽ chuyển từ Make sang sử dụng Soong càng sớm càng tốt. Gửi câu hỏi đến Nhóm Google xây dựng android để nhận hỗ trợ.

Soong là gì?

Hệ thống xây dựng Soong đã được giới thiệu trong Android 7.0 (Nougat) để thay thế Make. Nó tận dụng công cụ sao chép Kati GNU Make và thành phần hệ thống xây dựng Ninja để tăng tốc độ xây dựng Android.

Xem mô tả Android Make Build System trong Dự án mã nguồn mở Android (AOSP) để biết hướng dẫn chung và Build System Changes for Android.mk Writers để tìm hiểu về các sửa đổi cần thiết để thích ứng từ Make sang Soong.

Xem các mục liên quan đến bản dựng trong bảng thuật ngữ để biết định nghĩa về các thuật ngữ chính và tệp tham chiếu Soong để biết chi tiết đầy đủ.

So sánh Make và Soong

Dưới đây là so sánh Tạo cấu hình với Soong thực hiện tương tự trong tệp cấu hình Soong (Bản thiết kế hoặc .bp ).

làm ví dụ

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux

LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src

LOCAL_SRC_FILES := $(call \
     all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)

ví dụ

cc_library_shared {
     name: “libxmlrpc++”,

     rtti: true,
     cppflags: [
           “-Wall”,
           “-Werror”,
           “-fexceptions”,
     ],
     export_include_dirs: [“src”],
     srcs: [“src/**/*.cpp”],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

Xem Cấu hình bản dựng đơn giản để biết các ví dụ cấu hình Soong dành riêng cho thử nghiệm.

Định dạng tệp Android.bp

Theo thiết kế, các tệp Android.bp rất đơn giản. Chúng không chứa các điều kiện hoặc báo cáo luồng điều khiển; tất cả sự phức tạp được xử lý bằng logic xây dựng được viết bằng Go. Khi có thể, cú pháp và ngữ nghĩa của tệp Android.bp tương tự như tệp BUILD của Bazel .

mô-đun

Một mô-đun trong tệp Android.bp bắt đầu bằng một loại mô-đun, theo sau là một tập hợp các thuộc tính có name: "value", định dạng:

cc_binary {
    name: "gzip",
    srcs: ["src/test/minigzip.c"],
    shared_libs: ["libz"],
    stl: "none",
}

Mỗi mô-đun phải có một thuộc tính name và giá trị phải là duy nhất trên tất cả các tệp Android.bp , ngoại trừ các giá trị thuộc tính name trong không gian tên và mô-đun dựng sẵn, có thể lặp lại.

Thuộc tính srcs chỉ định các tệp nguồn được sử dụng để xây dựng mô-đun, dưới dạng danh sách các chuỗi. Bạn có thể tham chiếu đầu ra của các mô-đun khác tạo tệp nguồn, như genrule hoặc filegroup , bằng cách sử dụng cú pháp tham chiếu mô-đun ":<module-name>" .

Để biết danh sách các loại mô-đun hợp lệ và thuộc tính của chúng, hãy xem Tham khảo mô-đun Soong .

các loại

Các biến và thuộc tính được nhập mạnh, với các biến động dựa trên phép gán đầu tiên và các thuộc tính được đặt tĩnh theo loại mô-đun. Các loại được hỗ trợ là:

Booleans ( true hoặc false )
Số nguyên ( int )
Chuỗi ( "string" )
Danh sách các chuỗi ( ["string1", "string2"] )
Bản đồ ( {key1: "value1", key2: ["value2"]} )

Bản đồ có thể chứa các giá trị thuộc bất kỳ loại nào, kể cả bản đồ lồng nhau. Danh sách và bản đồ có thể có dấu phẩy sau giá trị cuối cùng.

quả cầu

Các thuộc tính lấy danh sách tệp, chẳng hạn như srcs , cũng có thể lấy các mẫu chung. Các mẫu hình cầu có thể chứa ký tự đại diện UNIX bình thường * , ví dụ *.java . Các mẫu hình cầu cũng có thể chứa một ký tự đại diện ** duy nhất làm phần tử đường dẫn, khớp với 0 hoặc nhiều phần tử đường dẫn. Ví dụ: java/**/*.java khớp với cả hai mẫu java/Main.java và java/com/android/Main.java .

Biến

Tệp Android.bp có thể chứa các phép gán biến cấp cao nhất:

gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
    name: "gzip",
    srcs: gzip_srcs,
    shared_libs: ["libz"],
    stl: "none",
}

Các biến được đặt trong phạm vi phần còn lại của tệp mà chúng được khai báo, cũng như bất kỳ tệp Blueprint con nào. Các biến là bất biến với một ngoại lệ: chúng có thể được thêm vào với phép gán += , nhưng chỉ trước khi chúng được tham chiếu.

Bình luận

Các tệp Android.bp có thể chứa nhiều dòng /* */ kiểu C và // nhận xét một dòng kiểu C++.

nhà điều hành

Các chuỗi, danh sách các chuỗi và bản đồ có thể được nối thêm bằng toán tử +. Các số nguyên có thể được tính tổng bằng toán tử + . Việc nối thêm một bản đồ sẽ tạo ra sự kết hợp của các khóa trong cả hai bản đồ, nối thêm các giá trị của bất kỳ khóa nào có trong cả hai bản đồ.

điều kiện

Soong không hỗ trợ điều kiện trong tệp Android.bp . Thay vào đó, sự phức tạp trong quy tắc xây dựng yêu cầu điều kiện được xử lý trong Go, nơi có thể sử dụng các tính năng ngôn ngữ cấp cao và có thể theo dõi các phụ thuộc ngầm do điều kiện đưa ra. Hầu hết các điều kiện được chuyển đổi thành thuộc tính bản đồ, trong đó một trong các giá trị trong bản đồ được chọn và nối vào thuộc tính cấp cao nhất.

Ví dụ: để hỗ trợ các tệp dành riêng cho kiến trúc:

cc_library {
    ...
    srcs: ["generic.cpp"],
    arch: {
        arm: {
            srcs: ["arm.cpp"],
        },
        x86: {
            srcs: ["x86.cpp"],
        },
    },
}

trình định dạng

Soong bao gồm một trình định dạng chuẩn cho các tệp Bản thiết kế, tương tự như gofmt . Để định dạng lại đệ quy tất cả các tệp Android.bp trong thư mục hiện tại, hãy chạy:

bpfmt -w .

Định dạng chính tắc bao gồm thụt lề bốn khoảng trắng, các dòng mới sau mỗi phần tử của danh sách nhiều phần tử và dấu phẩy ở cuối trong danh sách và bản đồ.

mô-đun đặc biệt

Một số nhóm mô-đun đặc biệt có những đặc điểm riêng.

mô-đun mặc định

Một mô-đun mặc định có thể được sử dụng để lặp lại các thuộc tính giống nhau trong nhiều mô-đun. Ví dụ:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

mô-đun dựng sẵn

Một số loại mô-đun dựng sẵn cho phép một mô-đun có cùng tên với các đối tác dựa trên nguồn của nó. Ví dụ: có thể có một cc_prebuilt_binary có tên là foo khi đã có một cc_binary có cùng tên. Điều này mang lại cho các nhà phát triển sự linh hoạt trong việc chọn phiên bản nào sẽ được đưa vào sản phẩm cuối cùng của họ. Nếu cấu hình bản dựng chứa cả hai phiên bản, giá trị cờ prefer trong định nghĩa mô-đun dựng sẵn sẽ chỉ ra phiên bản nào được ưu tiên. Lưu ý rằng một số mô-đun dựng sẵn có tên không bắt đầu bằng prebuilt , chẳng hạn như android_app_import .

mô-đun không gian tên

Cho đến khi Android chuyển đổi hoàn toàn từ Make sang Soong, cấu hình sản phẩm Make phải chỉ định giá trị PRODUCT_SOONG_NAMESPACES . Giá trị của nó phải là một danh sách các không gian tên được phân tách bằng dấu cách mà Soong xuất sang Make để được tạo bởi lệnh m . Sau khi quá trình chuyển đổi của Android sang Soong hoàn tất, các chi tiết về cách bật không gian tên có thể thay đổi.

Soong cung cấp khả năng cho các mô-đun trong các thư mục khác nhau chỉ định cùng một tên, miễn là mỗi mô-đun được khai báo trong một không gian tên riêng. Một không gian tên có thể được khai báo như sau:

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

Lưu ý rằng một không gian tên không có thuộc tính tên; đường dẫn của nó được tự động gán làm tên của nó.

Mỗi mô-đun Soong được gán một không gian tên dựa trên vị trí của nó trong cây. Mỗi mô-đun Soong được coi là nằm trong không gian tên được xác định bởi soong_namespace được tìm thấy trong tệp Android.bp trong thư mục hiện tại hoặc thư mục tổ tiên gần nhất. Nếu không tìm thấy mô-đun soong_namespace như vậy, thì mô-đun đó được coi là nằm trong không gian tên gốc ẩn.

Đây là một ví dụ: Soong cố gắng giải quyết sự phụ thuộc D được khai báo bởi mô-đun M trong không gian tên N nhập các không gian tên I1, I2, I3…

Sau đó, nếu D là một tên đủ điều kiện có dạng //namespace:module , thì chỉ không gian tên đã chỉ định được tìm kiếm cho tên mô-đun đã chỉ định.
Mặt khác, trước tiên Soong tìm kiếm một mô-đun có tên D được khai báo trong không gian tên N.
Nếu module đó không tồn tại, Soong sẽ tìm module có tên D trong các namespace I1, I2, I3…
Cuối cùng, Soong tìm trong không gian tên gốc.