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.

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 chính đáng cho việc đó một số bản vá không được chấp nhận ngược dòng và có những lịch biểu sản phẩm phải được đáp ứng, vì vậy một số bản vá được duy trì trong Android Common Kernel (ACK) để xây dựng GKI.

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ý.

Bản vá đã được gửi tới LKML nhưng không được chấp nhận kịp thời cho sản phẩm bản phát hành. 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 tới LKML và các nhận xét nhận được cho bản vá hoặc thời gian ước tính của bản vá được gửi ở thượng nguồ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 của bạn.
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 mà theo đó bản vá được tái cấu trúc được gửi ngược dòng (số liệu 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 tái cấu trúc bản vá ngược dòng để xem xét).
Bản vá không được chấp nhận ở quy trình ngược dòng (upstream) 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ó nhiều lý do khác dành cho bạn. Khi bạn gửi lỗi hoặc bản vá, đưa ra lý do hợp lệ và dự kiến lặp lại cũng như thảo luận. Chúng tôi nhận thấy ACK mang một số mảng, đặc biệt ở giai đoạn đầu của GKI, trong đó mọi người đều đang học cách ngược dòng nhưng không thể thư giãn sản phẩm để làm như vậy. Mong muốn đáp ứng các yêu cầu về phát trực tuyến nhiều 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

Bản vá được gửi tới ACK phải tuân thủ các tiêu chuẩn mã hoá kernel của 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 bản vá được chấp nhận ở luồng ngược dòng (upstream) hoặc trong android-mainline, bản vá đó có thể được điều chỉnh cho phiên bản cũ sang ACK dựa trên LTS thích hợp (chẳng hạn như android12-5.4 và android11-5.4 cho các bản vá giúp khắc phục 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 (upstream)

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

UPSTREAM: – Các bản vá được chọn từ "android-mainline" có thể sẽ là đượ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 duy 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 nó không có chuyển hướng). Có phải là vấn đề liên quan đến FROMLIST bản vá để tạo điều kiện cho việc thảo luận với nhóm nhân hệ điều hành Android.

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

Nếu không thể tải các thay đổi bắt buộc ở thượng nguồn, bạn có thể thử gửi các bản vá ngoài cây đến ACK trực tiếp. Cần gửi bản vá ngoài cây bạn tạo ra một vấn đề trong bộ phận CNTT và họ trích dẫn bản vá và giải thích lý do không thể gửi bản vá ở trạng thái ngược dòng (xem danh sách trước để biết ví dụ). Tuy nhiên, có một số trường hợp mà bạn không thể gửi mã ngược dòng. 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ả arm64 và x86 trừ phi CONFIG dành riêng cho từng 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. Bất kỳ hạng nào Thay đổi của CONFIG ảnh hưởng đến Giao diện mô-đun hạt nhân (KMI) sau khi bị từ chối. Trong trường hợp đối tác yêu cầu xung đột cho một cấu hình đơn lẻ, 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

Không thể gửi nội dung sửa đổi đối với mã đã dành riêng cho Android. Ví dụ: mặc dù trình điều khiển liên kết được duy trì ngược dòng, nhưng việc sửa đổi cho các tính năng kế thừa ưu tiên của trình điều khiển liên kết không thể gửi ngược dòng (upstream) vì chúng dành riêng cho Android. Hãy nêu rõ trong lỗi và vá lý do không thể gửi mã ngược dòng. 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 Upstream chủ động không khuyến khích hỗ trợ xây dựng 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 thử để yêu cầu EXPORT_SYMBOL_GPL() ngược dòng và cung cấp một mô-đun sử dụng biểu tượng mới được xuất, nếu có lý do hợp lệ cho lý do mô-đun chưa được gửi ngược dòng, bạn có thể gửi bản vá đến ACK. Bạn cần đưa ra lý do vì sao không thể ngược dòng mô-đun trong vấn đề. (Đừng yêu cầu biến thể không phải GPL, EXPORT_SYMBOL().)

Cấu hình bị ẩ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. Để phù hợp tạo mô-đun nằm 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 bị ẩn, hãy thêm câu lệnh select trong init/Kconfig.gki để cấu hình đó được chọn tự động 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 không ẩn cấu hình, 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 kernel (chẳng hạn như cpufreq) hỗ trợ các trình quản lý có thể tải, bạn có thể ghi đè thống đốc mặc định (chẳng hạn như thống đốc schedutil của cpufreq). Cho 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 để hỗ trợ thêm.

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

Trong các bản phát hành trước đây, bạn có thể thêm trực tiếp các nội dung sửa đổi theo nhà cung cấp cụ thể vào nhân hệ điều hành. 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, bạn có thể dùng thêm các cấu trúc dữ liệu chính các trường dữ liệu nhà cung cấp có sẵn để lưu trữ dữ liệu của từng 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ý. Một ví dụ về cách triển khai bao gồm các nội dung hook sau đây của nhà cung cấp.

Các hook thông thường của nhà cung cấp 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 nội dung hấp dẫn thông thường của nhà cung cấp sẽ bắt đầu bằng android_vh, vì vậy, tên của hook sched_exit() sẽ là android_vh_sched_exit.
Cần có các hook của nhà cung cấp bị hạn chế cho các trường hợp như hook của trình lập lịch biểu mà trong đó hàm đính kèm phải được gọi ngay cả khi CPU ngoại tuyến hoặc yêu cầu bối cảnh phi 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 nội dung hấp dẫn của nhà cung cấp, hãy báo cáo sự cố vào bộ phận CNTT và gửi bản vá (như với Bản vá dành riêng cho Android, phải có vấn đề và bạn phải cung cấp lý do). Chỉ hỗ trợ hook của nhà cung cấp trong ACK, vì vậy đừng gửi những nội dung này các bản vá cho phiên bản ngược dòng (upstream) của Linux.

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 của nhà cung cấp với các cấu trúc dữ liệu chính bằng cách thêm Trường android_vendor_data sử dụng macro ANDROID_VENDOR_DATA(). Cho 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 (Nhà sản xuất thiết bị gốc) 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 nội dung hấp dẫn của nhà cung cấp

Thêm các hook của nhà cung cấp vào mã nhân hệ điều hành làm điểm theo dõi bằng cách khai báo chúng bằng cách sử dụng DECLARE_HOOK() hoặc DECLARE_RESTRICTED_HOOK(), sau đó thêm chúng vào mã dưới dạng một đ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 nếu có được đính kèm. 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. Nội dung hấp dẫn phải được xác định 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 thực thể cho các giao diện cần thiết cho hook của nhà cung cấp, hãy thêm tệp tiêu đề bằng phần khai báo hook sang drivers/android/vendor_hooks.c và xuất . 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 Ý: Các cấu trúc dữ liệu dùng trong nội dung khai báo hook cần phải được được xác định đầy đủ để đảm bảo tính ổn định của ABI. 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. Bao gồm Định nghĩa đầy đủ về các cấu trúc dữ liệu này sẽ được trình bày bên trong Phần #ifndef __GENKSYMS__/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. Chuyển tiếp khai báo các loại.

Gắn vào nội dung hấp dẫn 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ý 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 nội dung hấp dẫn của nhà cung cấp từ tệp tiêu đề

Để sử dụng nội dung hấp dẫn của nhà cung cấp trong tệp tiêu đề, bạn có thể cần phải cập nhật nội dung hấp dẫn của nhà cung cấp tệp tiêu đề để không 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 không 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. Dùng tệp tiêu đề dành riêng cho nhà cung cấp để xác định giao diện giữa 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 mà 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 theo phần mềm của nhà cung cấp.
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ị).