Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

Phát triển mã nhân cho GKI

Hình ảnh hạt nhân chung (GKI) giúp giảm sự phân mảnh hạt nhân bằng cách căn chỉnh chặt chẽ bằng nhân hệ điều hành Linux ngược dòng. Tuy nhiên, có những lý do hợp lệ khiến một số bản vá không thể được chấp nhận ở thượng nguồn và có những lịch trình sản phẩm phải được đáp ứng, vì vậy, một số bản vá được duy trì trong các nguồn nhân kernel Android Common (ACK) mà từ đó GKI được tạo.

Nhà phát triển phải gửi các thay đổi về mã ở phiên bản ngược dòng bằng hệ thống Linux Kernel Mailing Liệt kê (LKML) làm lựa chọn đầu tiên và gửi các thay đổi mã tới ACK Nhánh android-mainline chỉ khi có lý do rõ ràng khiến luồng ngược dòng không hoạt động khả thi. Sau đây là ví dụ về các lý do hợp lệ và cách xử lý các lý do đó.

Bản vá đã được gửi đến LKML nhưng không được chấp nhận kịp thời để phát hành sản phẩm. Cách xử lý bản vá này:
- Cung cấp bằng chứng cho thấy bản vá đã được gửi đến LKML và nhận được nhận xét về bản vá hoặc thời gian ước tính để gửi bản vá lên trên.
- Quyết định hành động để đưa bản vá vào ACK, yêu cầu phê duyệt bản vá ngược dòng rồi lấy nó ra khỏi ACK khi phiên bản ngược dòng cuối cùng là được hợp nhất vào ACK.
Bản vá xác định EXPORT_SYMBOLS_GPL() cho mô-đun nhà cung cấp, nhưng không xác định được được gửi ngược dòng vì không có mô-đun trong cây nào sử dụng . Để xử lý bản vá này, hãy cung cấp thông tin chi tiết về lý do khiến mô-đun của bạn không thể gửi trước đây và các giải pháp thay thế mà bạn đã xem xét trước khi thực hiện yêu cầu.
Bản vá không đủ chung chung để phát triển và không có thời gian để và tái cấu trúc quảng cáo trước khi ra mắt sản phẩm. Để xử lý bản vá này, hãy cung cấp thời gian ước tính để gửi bản vá được tái cấu trúc lên trên (bản vá sẽ không được chấp nhận trong ACK nếu không có kế hoạch gửi bản vá được tái cấu trúc lên trên để xem xét).
Không thể chấp nhận bản vá này vì... <điền lý do đây>. Để xử lý bản vá này, hãy liên hệ với nhóm Android kernel và làm việc với chúng tôi về các phương án tái cấu trúc bản vá để có thể gửi bản vá để xem xét và được chấp nhận sau đó.

Có thể có rất nhiều lý do khác. Khi bạn gửi lỗi hoặc bản vá, hãy đưa ra lý do hợp lệ và dự kiến một số lần lặp lại và thảo luận. Chúng tôi nhận thấy ACK mang theo một số bản vá, đặc biệt là trong các giai đoạn đầu của GKI, trong khi mọi người đang tìm hiểu cách làm việc ngược dòng nhưng không thể nới lỏng lịch trình sản phẩm để làm như vậy. Dự kiến các yêu cầu về việc làm ngược dòng sẽ trở nên nghiêm ngặt hơn theo thời gian.

Yêu cầu về bản vá

Bản vá phải tuân thủ các tiêu chuẩn mã hoá hạt nhân Linux được mô tả trong Cây nguồn Linux, cho dù chúng được gửi ngược dòng (upstream) hay gửi tới ACK. scripts/checkpatch.pl tập lệnh này được chạy như một phần của thử nghiệm gửi trước khi gửi, vì vậy hãy chạy trước tập lệnh này để đảm bảo thành công. Để chạy tập lệnh bản vá kiểm tra có cùng cấu hình với thử nghiệm trước khi gửi, sử dụng //build/kernel/static_analysis:checkpatch_presubmit. Để biết thông tin chi tiết, hãy xem build/kernel/kleaf/docs/checkpatch.md.

Bản vá ACK

Các bản vá được gửi đến ACK phải tuân thủ các tiêu chuẩn lập trình hạt nhân Linux và nguyên tắc đóng góp. Bạn phải bao gồm một Change-Id trong thông báo cam kết; nếu bạn gửi bản vá đến nhiều nhánh (cho android-mainline và android12-5.4), bạn phải sử dụng cùng một Change-Id cho mọi bản vá.

Trước tiên, hãy gửi bản vá cho LKML để được xem xét ngược dòng. Nếu bản vá:

Được chấp nhận ở thượng nguồn, tệp này sẽ tự động được hợp nhất vào android-mainline.
Không được chấp nhận ở phiên bản ngược dòng, hãy gửi tệp này đến android-mainline bằng một nội dung gửi đến hoặc nội dung giải thích lý do nội dung đó không hoạt động được gửi tới LKML.

Sau khi một bản vá được chấp nhận ở thượng nguồn hoặc trong android-mainline, bản vá đó có thể được điều chỉnh cho phù hợp với ACK dựa trên LTS thích hợp (chẳng hạn như android12-5.4 và android11-5.4 đối với các bản vá sửa lỗi mã dành riêng cho Android). Đang gửi tới android-mainline cho phép kiểm thử với các bản phát hành ngược dòng (upstream) mới và đảm bảo rằng bản vá nằm trong ACK dựa trên LTS tiếp theo. Ngoại lệ bao gồm các trường hợp trong đó bản vá ngược dòng được điều chỉnh cho phiên bản cũ là android12-5.4 (vì bản vá này có thể đã tồn tại trong android-mainline).

Bản vá ngược dòng

Như đã chỉ định trong nguyên tắc đóng góp, các bản vá ngược dòng dành cho nhân ACK thuộc các nhóm sau (liệt kê theo thứ tự khả năng được chấp nhận).

UPSTREAM: – Các bản vá được chọn lọc từ "android-mainline" có thể được chấp nhận vào ACK nếu có trường hợp sử dụng hợp lý.
BACKPORT: – Bản vá từ thượng nguồn không được chọn sạch và cần thì các sửa đổi đó cũng có thể được chấp nhận nếu có cách sử dụng hợp lý trường hợp.
FROMGIT: – Các bản vá được chọn từ một nhánh duy trì để chuẩn bị để gửi tới dòng chính của Linux có thể được chấp nhận nếu có sự kiện sắp diễn ra hạn cuối. Những quy tắc này phải hợp lý về cả nội dung và lịch biểu.
FROMLIST: – Bản vá đã được gửi tới LKML nhưng chưa được gửi được chấp nhận vào một nhánh nhà bảo trì nhưng ít có khả năng được chấp nhận, trừ khi lý do đủ thuyết phục để người dùng có thể chấp nhận bản vá cho dù nó có được chuyển đến Linux ngược dòng hay không (chúng tôi giả định rằng mã sẽ không có). Phải có vấn đề liên quan đến các bản vá FROMLIST để tạo điều kiện thảo luận với nhóm nhân kernel Android.

Bản vá dành riêng cho Android

Nếu không thể đưa các thay đổi bắt buộc lên trên, bạn có thể thử gửi trực tiếp các bản vá ngoài cây cho ACK. Để gửi các bản vá ngoài cây, bạn cần tạo một vấn đề trong IT, trong đó trích dẫn bản vá và lý do tại sao không thể gửi bản vá lên trên (xem danh sách trước đó để biết ví dụ). Tuy nhiên, có một số trường hợp bạn không thể gửi mã lên trên. Các trường hợp được đề cập như sau và phải tuân thủ khoản đóng góp các nguyên tắc cho các bản vá dành riêng cho Android và được gắn thẻ bằng tiền tố ANDROID: trong chủ đề.

Các thay đổi đối với gki_defconfig

Tất cả thay đổi CONFIG đối với gki_defconfig phải được áp dụng cho cả phiên bản arm64 và x86, trừ phi CONFIG dành riêng cho cấu trúc. Cách yêu cầu thay đổi đối với chế độ cài đặt CONFIG, hãy tạo một vấn đề trong bộ phận CNTT để thảo luận về sự thay đổi này. Mọi thay đổi CONFIG ảnh hưởng đến Giao diện mô-đun hạt nhân (KMI) sau khi giao diện này bị đóng băng sẽ bị từ chối. Trong trường hợp đối tác yêu cầu các chế độ cài đặt xung đột cho một cấu hình, chúng tôi sẽ giải quyết xung đột thông qua thảo luận về các lỗi liên quan.

Mã không tồn tại ở thượng nguồn

Bạn không thể gửi các nội dung sửa đổi đối với mã dành riêng cho Android lên trên. Ví dụ: mặc dù trình điều khiển liên kết được duy trì ở thượng nguồn, nhưng bạn không thể gửi các nội dung sửa đổi đối với các tính năng kế thừa ưu tiên của trình điều khiển liên kết lên thượng nguồn vì các tính năng này dành riêng cho Android. Hãy nêu rõ lỗi và bản vá lý do không thể gửi mã lên trên. Nếu có thể, hãy chia các miếng vá thành nhiều phần có thể được gửi ngược dòng và các phần dành riêng cho Android mà không thể gửi ngược dòng để giảm thiểu số lượng mã ngoài cây được duy trì trong ACK.

Những thay đổi khác trong danh mục này là nội dung cập nhật đối với tệp biểu diễn KMI, KMI danh sách biểu tượng, gki_defconfig, tập lệnh bản dựng hoặc cấu hình hoặc các tập lệnh khác không tồn tại ở thượng nguồn.

Mô-đun ngoài cây

Linux ngược dòng chủ động không khuyến khích hỗ trợ việc tạo các mô-đun ngoài cây. Đây là một quan điểm hợp lý vì các nhà bảo trì Linux không đảm bảo về khả năng tương thích tệp nhị phân hoặc nguồn trong nhân và không muốn hỗ trợ mã không có trong cây. Tuy nhiên, GKI có đảm bảo cho ABI đối với các mô-đun của nhà cung cấp, đảm bảo rằng giao diện KMI ổn định theo vòng đời của một nhân. Do đó, có một loại thay đổi để hỗ trợ nhà cung cấp những mô-đun được chấp nhận cho ACK nhưng không được chấp nhận cho quá trình tải lên.

Ví dụ: hãy xem xét một bản vá thêm macro EXPORT_SYMBOL_GPL() trong đó các mô-đun sử dụng lệnh xuất dữ liệu không có trong cây nguồn. Mặc dù bạn phải cố gắng yêu cầu EXPORT_SYMBOL_GPL() ở thượng nguồn và cung cấp một mô-đun sử dụng biểu tượng mới xuất, nhưng nếu có lý do hợp lệ cho việc tại sao mô-đun không được gửi lên thượng nguồn, thì bạn có thể gửi bản vá cho ACK. Bạn cần đưa ra lý do giải thích tại sao không thể chuyển lên trên trong vấn đề. (Đừng yêu cầu biến thể không phải GPL, EXPORT_SYMBOL().)

Cấu hình ẩn

Một số mô-đun trong cây tự động chọn những cấu hình bị ẩn không thể chỉ định được trong gki_defconfig. Ví dụ: CONFIG_SND_SOC_TOPOLOGY được chọn tự động khi CONFIG_SND_SOC_SOF=y được định cấu hình. Để hỗ trợ việc xây dựng mô-đun ngoài cây, GKI có một cơ chế để bật các cấu hình ẩn.

Để bật một cấu hình ẩn, hãy thêm câu lệnh select trong init/Kconfig.gki để cấu hình đó được tự động chọn dựa trên cấu hình hạt nhân CONFIG_GKI_HACKS_TO_FIX được bật trong gki_defconfig. Chỉ sử dụng cơ chế này cho các cấu hình ẩn; nếu cấu hình không bị ẩn, bạn phải chỉ định cấu hình đó trong gki_defconfig một cách rõ ràng hoặc dưới dạng phần phụ thuộc.

Trình quản lý có thể tải

Đối với các khung nhân (chẳng hạn như cpufreq) hỗ trợ các trình quản lý tải, bạn có thể ghi đè trình quản lý mặc định (chẳng hạn như trình quản lý schedutil của cpufreq. Để các khung (chẳng hạn như khung nhiệt) không hỗ trợ các cấu trúc có thể tải hoặc trình điều khiển nào khác nhưng vẫn yêu cầu triển khai theo nhà cung cấp cụ thể, tạo ra vấn đề thuộc nhóm CNTT và tham khảo ý kiến của nhóm nhân hệ điều hành Android.

Chúng tôi sẽ làm việc với bạn và các nhà bảo trì cấp trên để thêm các tính năng hỗ trợ cần thiết.

Nội dung hấp dẫn của nhà cung cấp

Trong các bản phát hành trước, bạn có thể thêm các nội dung sửa đổi dành riêng cho nhà cung cấp trực tiếp vào hạt nhân lõi. Bạn không thể làm như vậy với GKI 2.0 vì mã dành riêng cho sản phẩm phải được triển khai trong các mô-đun và sẽ không được chấp nhận trong hạt nhân cốt lõi ngược dòng hoặc trong ACK. Để bật các tính năng giá trị gia tăng mà đối tác sử dụng mà không gây ảnh hưởng nhiều trên mã nhân hệ điều hành cốt lõi, GKI chấp nhận các hook của nhà cung cấp cho phép gọi các mô-đun từ mã nhân hệ điều hành lõi. Ngoài ra, các cấu trúc dữ liệu chính có thể được đệm bằng các trường dữ liệu của nhà cung cấp có sẵn để lưu trữ dữ liệu dành riêng cho nhà cung cấp nhằm triển khai các tính năng này.

hook của nhà cung cấp có hai biến thể (bình thường và bị hạn chế), dựa trên điểm theo dõi (không phải sự kiện theo dõi) mà mô-đun nhà cung cấp có thể đính kèm vào. Ví dụ: thay vì thêm một hàm sched_exit() mới để thực hiện công việc kế toán thoát, nhà cung cấp có thể thêm một hook trong do_exit() mà mô-đun nhà cung cấp có thể đính kèm vào để xử lý. Ví dụ về cách triển khai bao gồm các trình bổ trợ của nhà cung cấp sau.

Các trình bổ trợ nhà cung cấp thông thường sử dụng DECLARE_HOOK() để tạo hàm điểm theo dõi với tên trace_name, trong đó name là giá trị nhận dạng duy nhất cho dấu vết. Theo quy ước, tên của trình bổ trợ nhà cung cấp thông thường bắt đầu bằng android_vh, vì vậy, tên của trình bổ trợ sched_exit() sẽ là android_vh_sched_exit.
Bạn cần có các trình bổ trợ của nhà cung cấp bị hạn chế cho các trường hợp như trình bổ trợ của trình lập lịch biểu, trong đó hàm đính kèm phải được gọi ngay cả khi CPU đang ngoại tuyến hoặc yêu cầu ngữ cảnh không nguyên tử. Không thể tách các hook của nhà cung cấp bị hạn chế, vì vậy, các mô-đun mà đính kèm vào một hook bị hạn chế sẽ tuyệt đối không huỷ tải được. Bị hạn chế tên móc của nhà cung cấp bắt đầu bằng android_rvh.

Để thêm một trình bổ trợ của nhà cung cấp, hãy gửi vấn đề trong nhóm CNTT và gửi các bản vá (cũng như tất cả các bản vá dành riêng cho Android, bạn phải có một vấn đề và phải đưa ra lý do). Hỗ trợ cho các trình bổ trợ của nhà cung cấp chỉ có trong ACK, vì vậy, đừng gửi các bản vá này đến Linux ngược dòng.

Thêm các trường của nhà cung cấp vào cấu trúc

Bạn có thể liên kết dữ liệu nhà cung cấp với các cấu trúc dữ liệu chính bằng cách thêm các trường android_vendor_data bằng cách sử dụng macro ANDROID_VENDOR_DATA(). Ví dụ: để hỗ trợ các tính năng gia tăng giá trị, hãy thêm các trường vào cấu trúc như minh hoạ trong mã mẫu sau.

Để tránh xung đột tiềm ẩn giữa các trường mà nhà cung cấp và trường cần OEM (Nhà sản xuất thiết bị gốc) cần đến, OEM không bao giờ được sử dụng các trường được khai báo bằng ANDROID_VENDOR_DATA() macro. Thay vào đó, OEM phải sử dụng ANDROID_OEM_DATA() để khai báo các trường android_oem_data.

#include <linux/android_vendor.h>
...
struct important_kernel_data {
  [all the standard fields];
  /* Create vendor data for use by hook implementations. The
   * size of vendor data is based on vendor input. Vendor data
   * can be defined as single u64 fields like the following that
   * declares a single u64 field named "android_vendor_data1" :
   */
  ANDROID_VENDOR_DATA(1);

  /*
   * ...or an array can be declared. The following is equivalent to
   * u64 android_vendor_data2[20]:
   */
  ANDROID_VENDOR_DATA_ARRAY(2, 20);

  /*
   * SoC vendors must not use fields declared for OEMs and
   * OEMs must not use fields declared for SoC vendors.
   */
  ANDROID_OEM_DATA(1);

  /* no further fields */
}

Xác định trình bổ trợ của nhà cung cấp

Thêm các trình bổ trợ của nhà cung cấp vào mã hạt nhân dưới dạng điểm theo dõi bằng cách khai báo các trình bổ trợ đó bằng DECLARE_HOOK() hoặc DECLARE_RESTRICTED_HOOK(), sau đó thêm các trình bổ trợ đó vào mã dưới dạng điểm theo dõi. Ví dụ: để thêm trace_android_vh_sched_exit() vào hàm hạt nhân do_exit() hiện có:

#include <trace/hooks/exit.h>
void do_exit(long code)
{
    struct task_struct *tsk = current;
    ...
    trace_android_vh_sched_exit(tsk);
    ...
}

Ban đầu, hàm trace_android_vh_sched_exit() chỉ kiểm tra xem có nội dung nào được đính kèm hay không. Tuy nhiên, nếu mô-đun nhà cung cấp đăng ký trình xử lý bằng cách sử dụng register_trace_android_vh_sched_exit(), hàm đã đăng ký sẽ được gọi. Chiến lược phát hành đĩa đơn trình xử lý phải biết ngữ cảnh liên quan đến khoá được giữ, trạng thái RCS và các yếu tố khác. Bạn phải xác định trình bổ trợ trong tệp tiêu đề trong thư mục include/trace/hooks.

Ví dụ: đoạn mã sau đây đưa ra một nội dung khai báo khả thi cho trace_android_vh_sched_exit() trong tệp include/trace/hooks/exit.h.

/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM sched
#define TRACE_INCLUDE_PATH trace/hooks

#if !defined(_TRACE_HOOK_SCHED_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_HOOK_SCHED_H
#include <trace/hooks/vendor_hooks.h>
/*
 * Following tracepoints are not exported in tracefs and provide a
 * mechanism for vendor modules to hook and extend functionality
 */

struct task_struct;

DECLARE_HOOK(android_vh_sched_exit,
             TP_PROTO(struct task_struct *p),
             TP_ARGS(p));

#endif /* _TRACE_HOOK_SCHED_H */

/* This part must be outside protection */
#include <trace/define_trace.h>

Để tạo bản sao các giao diện cần thiết cho trình bổ trợ của nhà cung cấp, hãy thêm tệp tiêu đề có nội dung khai báo trình bổ trợ vào drivers/android/vendor_hooks.c và xuất các biểu tượng. Ví dụ: mã sau đây hoàn tất khai báo phần tử android_vh_sched_exit() hook.

#ifndef __GENKSYMS__
/* struct task_struct */
#include <linux/sched.h>
#endif

#define CREATE_TRACE_POINTS
#include <trace/hooks/vendor_hooks.h>
#include <trace/hooks/exit.h>
/*
 * Export tracepoints that act as a bare tracehook (i.e. have no trace
 * event associated with them) to allow external modules to probe
 * them.
 */
EXPORT_TRACEPOINT_SYMBOL_GPL(android_vh_sched_exit);

LƯU Ý: Bạn cần xác định đầy đủ các cấu trúc dữ liệu được sử dụng trong phần khai báo lệnh gọi lại để đảm bảo ABI ổn định. Nếu không, sẽ không an toàn để tham chiếu đến các con trỏ mờ hoặc sử dụng cấu trúc trong ngữ cảnh có kích thước. Phần bao gồm cung cấp định nghĩa đầy đủ về các cấu trúc dữ liệu như vậy phải nằm bên trong phần #ifndef __GENKSYMS__ của drivers/android/vendor_hooks.c. Tiêu đề các tệp trong include/trace/hooks không được bao gồm tệp tiêu đề hạt nhân có để tránh việc thay đổi CRC làm hỏng KMI. Thay vào đó, hãy chuyển tiếp khai báo các loại.

Đính kèm vào các trình bổ trợ của nhà cung cấp

Để sử dụng hook của nhà cung cấp, mô-đun nhà cung cấp cần đăng ký một trình xử lý cho hook (thường được thực hiện trong quá trình khởi chạy mô-đun). Ví dụ: mã sau đây cho thấy trình xử lý foo.ko của mô-đun dành cho trace_android_vh_sched_exit().

#include <trace/hooks/sched.h>
...
static void foo_sched_exit_handler(void *data, struct task_struct *p)
{
    foo_do_exit_accounting(p);
}
...
static int foo_probe(..)
{
    ...
    rc = register_trace_android_vh_sched_exit(foo_sched_exit_handler, NULL);
    ...
}

Sử dụng trình bổ trợ của nhà cung cấp từ tệp tiêu đề

Để sử dụng các trình bổ trợ của nhà cung cấp từ tệp tiêu đề, bạn có thể cần cập nhật tệp tiêu đề trình bổ trợ của nhà cung cấp để huỷ xác định TRACE_INCLUDE_PATH nhằm tránh các lỗi bản dựng cho biết không tìm thấy tệp tiêu đề điểm theo dõi. Ví dụ:

In file included from .../common/init/main.c:111:
In file included from .../common/include/trace/events/initcall.h:74:
.../common/include/trace/define_trace.h:95:10: fatal error: 'trace/hooks/initcall.h' file not found
   95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE'
   90 | # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system)
      |                                ^~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE'
   87 | # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h)
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:10:27: note: expanded from macro '__stringify'
   10 | #define __stringify(x...)       __stringify_1(x)
      |                                 ^~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1'
    9 | #define __stringify_1(x...)     #x
      |                                 ^~
<scratch space>:14:1: note: expanded from here
   14 | "trace/hooks/initcall.h"
      | ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Để khắc phục loại lỗi bản dựng này, hãy áp dụng bản sửa lỗi tương đương cho hook của nhà cung cấp tệp tiêu đề mà bạn đang đưa vào. Để biết thêm thông tin, hãy tham khảo https://r.android.com/3066703.

diff --git a/include/trace/hooks/mm.h b/include/trace/hooks/mm.h
index bc6de7e53d66..039926f7701d 100644
--- a/include/trace/hooks/mm.h
+++ b/include/trace/hooks/mm.h
@@ -2,7 +2,10 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM mm

+#ifdef CREATE_TRACE_POINTS
 #define TRACE_INCLUDE_PATH trace/hooks
+#define UNDEF_TRACE_INCLUDE_PATH
+#endif

Việc xác định UNDEF_TRACE_INCLUDE_PATH sẽ yêu cầu include/trace/define_trace.h huỷ xác định TRACE_INCLUDE_PATH sau khi tạo các điểm theo dõi.

Các tính năng cốt lõi trong kernel

Nếu không có kỹ thuật nào trước đây cho phép bạn triển khai một tính năng từ một mô-đun, thì bạn phải thêm tính năng đó dưới dạng nội dung sửa đổi dành riêng cho Android vào phần chính nhân hệ điều hành. Tạo một vấn đề trong công cụ theo dõi lỗi (IT) để bắt đầu trao đổi.

Giao diện lập trình ứng dụng người dùng (UAPI)

Tệp tiêu đề UAPI. Các thay đổi đối với Tệp tiêu đề UAPI phải diễn ra ngược dòng trừ phi thay đổi là đối với giao diện dành riêng cho Android. Sử dụng các tệp tiêu đề dành riêng cho nhà cung cấp để xác định giao diện giữa các mô-đun nhà cung cấp và mã không gian người dùng của nhà cung cấp.
nút sysfs. Không thêm các nút sysfs mới vào hạt nhân GKI (các bổ sung như vậy chỉ hợp lệ trong các mô-đun của nhà cung cấp). Các nút sysfs được SoC- và thư viện không phụ thuộc vào thiết bị và mã Java tạo nên khung Android chỉ có thể được thay đổi theo cách tương thích và phải được thay đổi ngược dòng nếu chúng không phải là nút sysfs dành riêng cho Android. Bạn có thể tạo các nút sysfs dành riêng cho nhà cung cấp để không gian người dùng của nhà cung cấp sử dụng. Theo mặc định, SELinux sẽ từ chối quyền truy cập vào các nút sysfs theo không gian người dùng. Điều này phụ thuộc vào thêm các nhãn SELinux thích hợp để cho phép truy cập bằng phần mềm của nhà cung cấp.
Các nút DebugFS. Mô-đun nhà cung cấp có thể xác định các nút trong debugfs cho chỉ gỡ lỗi (vì debugfs không được gắn kết trong quá trình hoạt động bình thường của thiết bị).