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 điều chỉnh cho phù hợp với hạt nhân Linux nguồn trên. Tuy nhiên, có những lý do chính đáng khiến một số bản vá không được chấp nhận ở nguồn thượng nguồn và có những lịch trình sản phẩm phải đáp ứng, vì vậy, một số bản vá được duy trì trong các nguồn Nhân chung Android (ACK) mà từ đó GKI được tạo.

Nhà phát triển phải gửi các thay đổi về mã nguồn lên nguồn chính bằng Danh sách gửi thư của nhân Linux (LKML) làm lựa chọn đầu tiên và chỉ gửi các thay đổi về mã nguồn cho nhánh ACK android-mainline khi có lý do chính đáng cho thấy nguồn chính khô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 cho một bản 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à các bình luận nhận được cho bản vá đó, hoặc thời gian ước tính mà bản vá được gửi lên nguồn.
- Quyết định cách thức để đưa bản vá vào ACK, được phê duyệt ở nguồn trên, rồi đưa bản vá ra khỏi ACK khi phiên bản nguồn trên cuối cùng được hợp nhất vào ACK.
Bản vá xác định EXPORT_SYMBOLS_GPL() cho một mô-đun của nhà cung cấp, nhưng không thể gửi lên nguồn vì không có mô-đun trong cây nào sử dụng biểu tượng đó. Để xử lý bản vá này, hãy cung cấp thông tin chi tiết về lý do bạn không thể gửi mô-đun lên nguồn và các phương án thay thế mà bạn đã cân nhắc trước khi đưa ra yêu cầu này.
Bản vá không đủ chung chung để truyền lên nguồn và không có thời gian để tái cấu trúc trước khi phát hành sản phẩm. Để xử lý bản vá này, hãy cung cấp thời gian ước tính mà bạn sẽ gửi bản vá được tái cấu trúc lên nguồn (bản vá sẽ không được chấp nhận trong ACK nếu bạn không có kế hoạch gửi bản vá được tái cấu trúc lên nguồn để xem xét).
Bản vá này không được chấp nhận bởi nguồn gốc vì... <insert reason here>. Để xử lý bản vá này, hãy liên hệ với nhóm hạt nhân Android và hợp tác với chúng tôi về các lựa chọn tái cấu trúc bản vá để có thể gửi bản vá đi xem xét và được chấp nhận ở nguồn trên.

Còn rất nhiều lý do tiềm ẩn 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 sẽ có một số lần lặp lại và thảo luận. Chúng tôi nhận thấy ACK có một số bản vá, đặc biệt là trong các giai đoạn đầu của GKI 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. Hãy dự kiến các yêu cầu về việc chuyển lên nguồn sẽ trở nên nghiêm ngặt hơn theo thời gian.

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

Các bản vá phải tuân thủ tiêu chuẩn mã hoá của nhân Linux được mô tả trong cây nguồn Linux, cho dù chúng được gửi ngược dòng hay đến ACK. Tập lệnh scripts/checkpatch.pl được chạy trong quá trình kiểm thử trước khi gửi của Gerrit, vì vậy, hãy chạy tập lệnh này trước để đảm bảo tập lệnh vượt qua quy trình kiểm thử. Để chạy tập lệnh checkpatch với cùng cấu hình như kiểm thử trước khi gửi, hãy 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 mã hoá của nhân Linux và nguyên tắc đóng góp. Bạn phải thêm thẻ Change-Id vào thông báo cam kết; nếu gửi bản vá cho nhiều nhánh (ví dụ: android-mainline và android12-5.4), bạn phải sử dụng cùng một Change-Id cho tất cả các phiên bản của bản vá.

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

Được chấp nhận ở nguồn, nó sẽ tự động hợp nhất vào android-mainline.
Không được chấp nhận ở nguồn trên, hãy gửi đến android-mainline kèm theo thông tin tham chiếu đến bản gửi ở nguồn trên hoặc giải thích lý do không gửi đến LKML.

Sau khi được chấp nhận ở nguồn gốc hoặc trong android-mainline, bản vá có thể được chuyển ngược về 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á khắc phục mã dành riêng cho Android). Việc gửi đến android-mainline cho phép kiểm thử bằng các bản phát hành đề xuất mới ở nguồn trên và đảm bảo rằng bản vá nằm trong ACK dựa trên LTS tiếp theo. Quy tắc này không áp dụng cho các trường hợp bản vá ngược dòng được chuyển ngược về android12-5.4 (vì bản vá có thể đã có trong android-mainline).

Bản vá nguồn

Như được chỉ định trong nguyên tắc đóng góp, các bản vá nguồn dành cho 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 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: – Các bản vá từ nguồn thượng nguồn không chọn lọc một cách rõ ràng và cần được sửa đổi cũng có khả năng được chấp nhận nếu có trường hợp sử dụng hợp lý.
FROMGIT: – Các bản vá được chọn lọc từ một nhánh duy trì để chuẩn bị gửi đến nhánh chính của Linux có thể được chấp nhận nếu sắp đến thời hạn. Bạn phải đưa ra lý do chính đáng cho cả nội dung và lịch phát sóng.
FROMLIST: – Các bản vá đã được gửi đến LKML nhưng chưa được chấp nhận vào một nhánh duy trì thì khó có thể được chấp nhận, trừ phi lý do đủ thuyết phục để bản vá được chấp nhận cho dù có nằm trong Linux nguồn hay không (chúng tôi giả định rằng bản vá sẽ không được chấp nhận). Phải có một 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 hạt nhân Android.

Các bản vá dành riêng cho Android

Nếu không thể thực hiện các thay đổi bắt buộc ở nguồ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 nhóm CNTT có trích dẫn bản vá và lý do tại sao không thể gửi bản vá lên nguồn (xem danh sách trước để biết ví dụ). Tuy nhiên, có một số trường hợp mã không thể được gửi lên nguồn. Những trường hợp này được đề cập như sau và phải tuân theo nguyên tắc đóng góp đối với các bản vá dành riêng cho Android, đồng thời phải được gắn thẻ bằng tiền tố ANDROID: trong tiêu đề.

Thay đổi đối với gki_defconfig

Tất cả các thay đổi về CONFIG đối với gki_defconfig đều phải được áp dụng cho cả phiên bản arm64 và x86, trừ phi CONFIG dành riêng cho một cấu trúc. Để yêu cầu thay đổi chế độ cài đặt CONFIG, hãy tạo một vấn đề trong bộ phận CNTT để thảo luận về thay đổi đó. Mọi thay đổi CONFIG ảnh hưởng đến Giao diện mô-đun hạt nhân (KMI) sau khi KMI bị đóng băng đều 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 duy nhất, 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 ở nguồn gốc

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 nguồn. Ví dụ: mặc dù trình điều khiển liên kết được duy trì ở nguồn trên, nhưng không thể gửi các nội dung sửa đổi đối với tính năng kế thừa mức độ ưu tiên của trình điều khiển liên kết lên nguồn trên vì chúng dành riêng cho Android. Hãy nêu rõ lỗi và bản vá của bạn về lý do không thể gửi mã lên nguồn. Nếu có thể, hãy chia các bản vá thành những phần có thể gửi lên nguồn và những phần dành riêng cho Android không thể gửi lên nguồn để giảm thiểu 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à các bản cập nhật đối với tệp biểu thị KMI, danh sách biểu tượng KMI, 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 ở nguồn gốc.

Mô-đun ngoài cây

Linux nguồn trên đang tích cực ngăn chặn việc hỗ trợ tạo các mô-đun ngoài cây. Đây là một lập trường hợp lý vì những người duy trì Linux không đảm bảo khả năng tương thích 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 ABI cho các mô-đun của nhà cung cấp, đảm bảo rằng các giao diện KMI ổn định trong thời gian hỗ trợ của một nhân. Do đó, có một nhóm các thay đổi để hỗ trợ các mô-đun của nhà cung cấp có thể chấp nhận được đối với ACK nhưng không chấp nhận được đối với nguồn dữ liệu.

Ví dụ: hãy xem xét một bản vá thêm các macro EXPORT_SYMBOL_GPL() trong đó các mô-đun sử dụng tệp xuất 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() ở nguồn trê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 chính đáng cho việc mô-đun không được gửi ở nguồn trên, bạn có thể gửi bản vá cho ACK. Bạn cần nêu lý do tại sao không thể chuyển mô-đun lên nguồn trong vấn đề này. (Khô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 sẽ tự động chọn các cấu hình ẩn mà bạn không thể chỉ định trong gki_defconfig. Ví dụ: CONFIG_SND_SOC_TOPOLOGY sẽ tự động được chọn khi bạn định cấu hình CONFIG_SND_SOC_SOF=y. Để đáp ứng việc tạo mô-đun ngoài cây, GKI bao gồm một cơ chế cho phép 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 vào init/Kconfig.gki để câu lệnh này tự động được 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 ẩ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 một phần phụ thuộc.

Thống đốc có thể tải

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

Chúng tôi sẽ hợp tác với bạn và những người duy trì nguồn gốc để thêm chế độ hỗ trợ cần thiết.

Hook của nhà cung cấp

Trong các bản phát hành trước đây, bạn có thể thêm các sửa đổi dành riêng cho nhà cung cấp trực tiếp vào nhân cốt lõi. Điều này không thể thực hiện được 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 các nhân chính nguồn trên hoặc trong ACK. Để bật các tính năng gia tăng mà đối tác dựa vào với tác động tối thiểu lên mã nhân cốt lõi, GKI chấp nhận các lệnh gọi của nhà cung cấp cho phép các mô-đun được gọi từ mã nhân cốt lõi. Ngoài ra, bạn có thể thêm các trường dữ liệu của nhà cung cấp vào cấu trúc dữ liệu chính để 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.

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

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

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

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ẫu mã sau.

Để tránh xung đột tiềm ẩn giữa các trường mà nhà cung cấp cần và các trường mà OEM cần, OEM không bao giờ được sử dụng các trường được khai báo bằng macro ANDROID_VENDOR_DATA(). Thay vào đó, các 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 các hook của nhà cung cấp

Thêm các lệnh gọi của nhà cung cấp vào mã kernel dưới dạng các điểm theo dõi bằng cách khai báo chúng bằng DECLARE_HOOK() hoặc DECLARE_RESTRICTED_HOOK(), rồi 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 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ó tệp nào được đính kèm hay không. Tuy nhiên, nếu một mô-đun nhà cung cấp đăng ký một trình xử lý bằng cách sử dụng register_trace_android_vh_sched_exit(), thì hàm đã đăng ký sẽ được gọi. Trình xử lý phải nhận biết được ngữ cảnh liên quan đến các khoá đã giữ, trạng thái RCS và các yếu tố khác. Bạn phải xác định lệnh gọi trong tệp tiêu đề trong thư mục include/trace/hooks.

Ví dụ: mã sau đây đưa ra một khai báo có thể có 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>

Để khởi tạo 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 đề có khai báo hook 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 việc khai báo hook android_vh_sched_exit().

#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 được dùng trong khai báo hook cần được xác định đầy đủ để đảm bảo tính ổn định của ABI. Nếu không, việc huỷ tham chiếu các con trỏ mờ hoặc sử dụng cấu trúc trong các bối cảnh có kích thước sẽ không an toàn. Phần include cung cấp định nghĩa đầy đủ về các cấu trúc dữ liệu như vậy phải nằm trong phần #ifndef __GENKSYMS__ của drivers/android/vendor_hooks.c. Các tệp tiêu đề trong include/trace/hooks không được bao gồm tệp tiêu đề của nhân có các định nghĩa về loại để tránh cá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 lệnh gọi của nhà cung cấp

Để sử dụng các lệnh gọi của nhà cung cấp, mô-đun của nhà cung cấp cần đăng ký một trình xử lý cho lệnh gọi (thường được thực hiện trong quá trình khởi tạo mô-đun). Ví dụ: mã sau đây cho thấy trình xử lý mô-đun foo.ko 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 các hook của nhà cung cấp từ tệp tiêu đề

Để sử dụng các lệnh gọi 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 đề lệnh gọi 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 tệp tiêu đề của lệnh gọi lại dành cho nhà cung cấp 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 của nhân

Nếu không có kỹ thuật nào ở trên 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 nhân cốt lõi. Tạo một vấn đề trong trình theo dõi vấn đề (IT) để bắt đầu cuộc trò chuyện.

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 ở nguồn gốc, trừ phi các thay đổi đó là đối với các 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 các giao diện giữa các mô-đun của nhà cung cấp và mã không gian người dùng của nhà cung cấp.
các nút sysfs. Không thêm các nút sysfs mới vào nhân GKI (những nội dung 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 do các thư viện độc lập với SoC và thiết bị cũng như 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à các 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 để người dùng không gian người dùng của nhà cung cấp sử dụng. Theo mặc định, quyền truy cập vào các nút sysfs của không gian người dùng sẽ bị từ chối bằng SELinux. Nhà cung cấp có trách nhiệm thêm các nhãn SELinux thích hợp để cho phép phần mềm được uỷ quyền của nhà cung cấp truy cập.
Các nút DebugFS. Các mô-đun của nhà cung cấp chỉ có thể xác định các nút trong debugfs để gỡ lỗi (vì debugfs không được gắn trong quá trình hoạt động bình thường của thiết bị).

Phát triển mã nhân cho GKI Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.