החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.

דף זה תורגם על ידי Cloud Translation API.

פיתוח קוד ליבה ל-GKI

Generic Kernel Image‏ (GKI) מפחית את הפיצול של הליבה על ידי התאמה הדוקה לליבה של Linux ב-upstream. עם זאת, יש סיבות לגיטימיות לכך שחלק מהתיקונים לא יכולים להתקבל ב-upstream, ויש לוחות זמנים למוצרים שצריך לעמוד בהם. לכן, חלק מהתיקונים נשמרים במקורות של Android Common Kernel‏ (ACK) שמהם נוצר GKI.

המפתחים צריכים לשלוח שינויים בקוד למקור (upstream) באמצעות רשימת התפוצה של Linux Kernel (LKML) כאפשרות הראשונה, ולשלוח שינויים בקוד להסתעפות ACKandroid-mainline רק אם יש סיבה טובה לכך שהאפשרות של שליחת השינויים למקור לא מתאימה. בהמשך מפורטות דוגמאות לסיבות חוקיות ודרכים לטיפול בהן.

התיקון נשלח ל-LKML, אבל לא אושר בזמן כדי שיתאפשר להשיק את המוצר. כדי לטפל בתיקון הזה:
- יש לספק הוכחה לכך שהתיקון נשלח ל-LKML וקיבל תגובות, או ציון זמן משוער שבו התיקון יישלח ל-upstream.
- להחליט על דרך פעולה להטמעת התיקון ב-ACK, לקבל אישור למעלה בזרם (upstream) ואז להסיר אותו מ-ACK כשהגרסה הסופית של upstream תשולב ב-ACK.
התיקון מגדיר את EXPORT_SYMBOLS_GPL() למודול של ספק, אבל לא ניתן היה לשלוח אותו ל-upstream כי אין מודולים בעץ שמשתמשים בסמל הזה. כדי לטפל בתיקון הזה, עליך לספק פרטים על הסיבה לכך שלא ניתן לשלוח את המודול ל-upstream, ועל האפשרויות החלופיות שבדקת לפני שליחת הבקשה.
התיקון לא מספיק כללי כדי להשתמש בו ב-upstream, ואין זמן לבצע בו refactoring לפני השקת המוצר. כדי לטפל בתיקון הזה, עליך לציין מתי תשלחו תיקון שעבר רה-פירמנטציה למקור (התיקון לא יתקבל ב-ACK בלי תוכנית לשליחת תיקון שעבר רה-פירמנטציה למקור לבדיקה).
אי אפשר לקבל את התיקון ב-upstream כי… <insert reason here>. כדי לטפל בתיקון הזה, צריך לפנות לצוות הליבה של Android ולעבוד איתנו על אפשרויות לשינוי מבנה התיקון כדי שניתן יהיה לשלוח אותו לבדיקה ולאשר אותו ב-upstream.

יש עוד הרבה סיבות אפשריות. כששולחים את הבאג או התיקון, צריך לכלול הצדקה תקפה ולצפות לסבב של שיפורים ודיונים. אנחנו מבינים ש-ACK כולל תיקונים מסוימים, במיוחד בשלבים המוקדמים של GKI, כשכולם לומדים איך לעבוד ב-upstream אבל לא יכולים לשנות את לוחות הזמנים של המוצרים כדי לעשות זאת. עם הזמן, הדרישות להעלאה ל-upstream יהיו מחמירות יותר.

דרישות לגבי תיקונים

התיקונים צריכים לעמוד בתקני הקוד של ליבה של Linux שמתוארים בעץ המקור של Linux, בין שהם נשלחים ל-upstream ובין שהם נשלחים ל-ACK. הסקריפט scripts/checkpatch.pl מופעל כחלק מבדיקת טרום-שליחת השינויים ב-Gerrit, לכן כדאי להריץ אותו מראש כדי לוודא שהוא עובר. כדי להריץ את סקריפט checkpatch עם אותה הגדרה כמו בבדיקות המקדימות לשליחה, משתמשים ב-//build/kernel/static_analysis:checkpatch_presubmit. פרטים נוספים זמינים במאמר build/kernel/kleaf/docs/checkpatch.md.

תיקוני ACK

תיקונים שנשלחים ל-ACK חייבים לעמוד בסטנדרטים של קוד הליבה של Linux ובהנחיות לתרומות. צריך לכלול תג Change-Id בהודעת השמירה. אם שולחים את התיקון לכמה הסתעפויות (למשל, android-mainline ו-android12-5.4), צריך להשתמש באותו Change-Id בכל המופעים של התיקון.

קודם צריך לשלוח את התיקונים ל-LKML לבדיקה ב-upstream. אם התיקון הוא:

אחרי שהיא תאושר ב-upstream, היא תתמזג באופן אוטומטי עם android-mainline.
לא התקבלה ב-upstream, שולחים אותה אל android-mainline עם הפניה לשליחה ל-upstream או הסבר למה היא לא נשלחה ל-LKML.

אחרי שתיקון מתקבל ב-upstream או ב-android-mainline, אפשר להעביר אותו לאחור (backport) למהדורת ה-ACK המתאימה מבוססת-LTS (למשל android12-5.4 ו-android11-5.4 לתיקונים שמתקנים קוד ספציפי ל-Android). שליחת בקשה ל-android-mainline מאפשרת בדיקה עם גרסאות מועמדות חדשות ל-upstream, ומבטיחה שהתיקון יהיה ב-ACK הבא שמבוסס על LTS. החרגות כוללות מקרים שבהם תיקון מ-upstream מועבר ל-android12-5.4 (כי סביר להניח שהתיקון כבר נמצא ב-android-mainline).

תיקונים ב-upstream

כפי שמפורט בהנחיות לשליחת תרומות, תיקוני upstream שמיועדים לליבת ACK נכללים בקבוצות הבאות (הרשימה מפורטת לפי הסבירות לקבלה).

UPSTREAM: – תיקונים שנבחרו בקפידה מ-'android-mainline' צפויים להתקבל ל-ACK אם יש להם תרחיש לדוגמה סביר.
BACKPORT: – תיקונים מ-upstream שלא מבצעים בחירה מדויקת של שינויים ודורשים שינוי, צפויים להתקבל גם אם יש מקרה שימוש סביר.
FROMGIT: – תיקונים שנבחרו בקפידה מענף של מנהל תוכנה לקראת שליחה ל-Linux mainline עשויים להתקבל אם יש מועד הגשה קרוב. צריך להצדיק את הבקשות האלה גם לגבי התוכן וגם לגבי לוח הזמנים.
FROMLIST: – תיקונים שנשלחו ל-LKML אבל עדיין לא אושרו להוספה להסתעפות של המנהל, לא צפויים להתקבל, אלא אם ההצדקה מספיק משכנעת כדי שהתיקון יתקבל גם אם הוא לא ייכלל ב-Linux למקור (אנחנו מניחים שהוא לא ייכלל). כדי לאפשר דיון עם צוות הליבה של Android, צריכה להיות בעיה שקשורה לתיקוני FROMLIST.

תיקונים ספציפיים ל-Android

אם אתם לא מצליחים להטמיע את השינויים הנדרשים ב-upstream, תוכלו לנסות לשלוח תיקונים מחוץ לעץ ישירות ל-ACK. כדי לשלוח תיקונים מחוץ לעץ, צריך ליצור פנייה ב-IT עם ציון התיקון והסיבה לכך שלא ניתן לשלוח אותו ל-upstream (דוגמאות מפורטות ברשימה הקודמת). עם זאת, יש כמה מקרים שבהם אי אפשר לשלוח את הקוד ל-upstream. הבקשות האלה מטופלות באופן הבא, ועליך לפעול בהתאם להנחיות לשליחת תיקונים לתיקונים ספציפיים ל-Android, ולתייג את הנושא בתחילית ANDROID:.

שינויים ב-gki_defconfig

צריך להחיל את כל השינויים ב-CONFIG ב-gki_defconfig גם בגרסה ל-arm64 וגם בגרסה ל-x86, אלא אם ה-CONFIG הוא ספציפי לארכיטקטורה. כדי לבקש שינוי בהגדרה של CONFIG, צריך ליצור פנייה ב-IT כדי לדון בשינוי. כל שינוי ב-CONFIG שמשפיע על Kernel Module Interface‏ (KMI) אחרי שהוא קופא נדחה. במקרים שבהם שותפים מבקשים הגדרות סותרות בתצורה אחת, אנחנו פותרים את הבעיות באמצעות דיון בבאגים הרלוונטיים.

קוד שלא קיים ב-upstream

לא ניתן לשלוח שינויים בקוד שכבר ספציפי ל-Android. לדוגמה, למרות שמנהלי ה-binder נשמרים ב-upstream, אי אפשר לשלוח שינויים בתכונות של ירושת העדיפות של מנהלי ה-binder ל-upstream כי הן ספציפיות ל-Android. יש לציין במדויק בבאג ובתיקון למה אי אפשר לשלוח את הקוד ל-upstream. אם אפשר, כדאי לפצל את התיקונים לחלקים שאפשר לשלוח למקור (upstream) ולחלקים ספציפיים ל-Android שאי אפשר לשלוח למקור, כדי לצמצם את כמות הקוד מחוץ לעץ שמנוהל ב-ACK.

שינויים אחרים בקטגוריה הזו הם עדכונים בקובצי ייצוג של KMI, ברשימות סמלים של KMI, ב-gki_defconfig, בסקריפטים ל-build או בתצורה, או בסקריפטים אחרים שלא קיימים ב-upstream.

מודולים מחוץ לעץ

ב-Upstream Linux לא מעודדים תמיכה ביצירת מודולים מחוץ לעץ. זו עמדה סבירה, מכיוון שמנהלי Linux לא מבטיחים תאימות לקוד המקור או לקוד הבינארי בליבה, והם לא רוצים לתמוך בקוד שלא נמצא בעץ. עם זאת, GKI כן מבטיח ABI למודול של הספק, כדי לוודא שממשקי KMI יהיו יציבים במשך כל תוחלת החיים הנתמכת של הליבה. לכן, יש סוג של שינויים לתמיכה במודולים של ספקים שמתאימים ל-ACK אבל לא מתאימים למקור.

לדוגמה, נניח שיש תיקון שמוסיף מאקרו EXPORT_SYMBOL_GPL(), והמודולים שמשתמשים בייצוא לא נמצאים בעץ המקור. אתם צריכים לנסות לבקש את EXPORT_SYMBOL_GPL() ב-upstream ולספק מודול שמשתמש בסמל שיוצאו לאחרונה. עם זאת, אם יש הצדקה תקפה לכך שהמודול לא נשלח ל-upstream, תוכלו לשלוח את התיקון ל-ACK במקום זאת. צריך לכלול בבעיה את ההצדקה לכך שלא ניתן להעביר את המודול ל-upstream. (לא מבקשים את הווריאנט שאינו GPL, EXPORT_SYMBOL()).

הגדרות מוסתרות

חלק מהמודולים שבתוך העץ בוחרים באופן אוטומטי הגדרות מוסתרות שלא ניתן לציין ב-gki_defconfig. לדוגמה, CONFIG_SND_SOC_TOPOLOGY נבחר באופן אוטומטי כשCONFIG_SND_SOC_SOF=y מוגדר. כדי לאפשר פיתוח של מודולים מחוץ לעץ, GKI כולל מנגנון להפעלת הגדרות מוסתרות.

כדי להפעיל הגדרה מוסתרת, מוסיפים משפט select בקובץ init/Kconfig.gki כדי שהיא תיבחר באופן אוטומטי על סמך הגדרת הליבה CONFIG_GKI_HACKS_TO_FIX, שמופעלת בקובץ gki_defconfig. יש להשתמש במנגנון הזה רק להגדרות מוסתרות. אם ההגדרה לא מוסתרת, צריך לציין אותה ב-gki_defconfig באופן מפורש או כיחסי תלות.

מושלים שניתן לטעון

במסגרות ליבה (כמו cpufreq) שתומכות ב-governors שניתן לטעון, אפשר לשנות את הגדרת ברירת המחדל של ה-governor (למשל, ה-governor schedutil של cpufreq). אם מדובר במסגרות (כמו המסגרת התרמית) שלא תומכות במנהלי התקנים או בדרייברים שניתנים לטעינה, אבל עדיין דורשות הטמעה ספציפית לספק, צריך ליצור דיווח ב-IT ולהתייעץ עם צוות הליבה של Android.

אנחנו נעזור לכם להוסיף את התמיכה הנדרשת, בשיתוף עם המטפלים בקוד המקור.

קטעי הוּק (hooks) של ספקים

בגרסאות קודמות, אפשר היה להוסיף שינויים ספציפיים לספק ישירות לליבת הליבה. אי אפשר לעשות זאת באמצעות GKI 2.0 כי קוד ספציפי למוצר צריך להיות מוטמע במודולים, ולא יתקבל ב-ACK או ב-upstream של הליבות של הליבה. כדי להפעיל תכונות מורחבות שהשותפים מסתמכים עליהן עם השפעה מינימלית על קוד הליבה, GKI מקבל ווקים של ספקים שמאפשרים להפעיל מודולים מקוד הליבה. בנוסף, כדי להטמיע את התכונות האלה, אפשר להוסיף למבנים של נתוני המפתח שדות של נתוני ספקים שזמינים לאחסון נתונים ספציפיים לספק.

יש שני סוגים של ווקים של ספקים (רגילים ומסוגרים) שמבוססים על נקודות מעקב (לא אירועי מעקב) שמודולים של ספקים יכולים לצרף אליהם. לדוגמה, במקום להוסיף פונקציית sched_exit() חדשה לצורך ניהול חשבונות בסיום המשימה, ספקים יכולים להוסיף הוק ב-do_exit() שאליו מודול של ספק יכול להתחבר לצורך עיבוד. דוגמה להטמעה כוללת את ה-hooks הבאים של הספק.

ב-hook רגיל של ספק נעשה שימוש ב-DECLARE_HOOK() כדי ליצור פונקציית tracepoint בשם trace_name, כאשר name הוא המזהה הייחודי של המעקב. לפי הסכמה, שמות הווקים הרגילים של ספקים מתחילים ב-android_vh, כך שהשם של הוווק sched_exit() יהיה android_vh_sched_exit.
צריך להשתמש ב-hooks מוגבלים של ספקים במקרים כמו ווקים של מתזמן, שבהם צריך להפעיל את הפונקציה המצורפת גם אם המעבד (CPU) במצב אופליין או אם נדרש הקשר לא אטומי. אי אפשר לנתק ווקים מוגבלים של ספקים, ולכן תמיד יהיה אפשר לפרוק מודולים שמצורפים לווקים מוגבלים. שמות של ווקים מוגבלים של ספקים מתחילים ב-android_rvh.

כדי להוסיף וו של ספק, צריך לדווח על בעיה ב-IT ולשלוח תיקונים (כמו בכל התיקונים הספציפיים ל-Android, צריכה להיות בעיה וצריך לספק הצדקה). התמיכה ב-hooks של ספקים קיימת רק ב-ACK, לכן אל תשלחו את התיקונים האלה ל-upstream Linux.

הוספת שדות של ספקים למבנים

כדי לשייך נתוני ספקים למבנים של נתוני מפתח, מוסיפים שדות android_vendor_data באמצעות המאקרו ANDROID_VENDOR_DATA(). לדוגמה, כדי לתמוך בתכונות עם ערך מוסף, מוסיפים שדות למבנים כפי שמתואר בדוגמת הקוד הבאה.

כדי למנוע התנגשויות פוטנציאליות בין שדות שנדרשים לספקים לבין שדות שנדרשים ליצרני ציוד מקורי (OEM), יצרני ציוד מקורי (OEM) לעולם לא יכולים להשתמש בשדות שהוגדרו באמצעות מאקרו ANDROID_VENDOR_DATA(). במקום זאת, יצרני ציוד מקורי צריכים להשתמש ב-ANDROID_OEM_DATA() כדי להצהיר על שדות 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 */
}

הגדרת ווקים של ספקים

כדי להוסיף ווקים של ספקים לקוד הליבה בתור נקודות מעקב, מכריזים עליהם באמצעות DECLARE_HOOK() או DECLARE_RESTRICTED_HOOK() ואז מוסיפים אותם לקוד בתור נקודת מעקב. לדוגמה, כדי להוסיף את trace_android_vh_sched_exit() לפונקציית הליבה הקיימת do_exit():

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

הפונקציה trace_android_vh_sched_exit() בודקת בהתחלה רק אם משהו מצורף. עם זאת, אם מודול של ספק רושם טיפול באמצעות register_trace_android_vh_sched_exit(), הפונקציה הרשומה נקראת. הטיפול צריך להיות מודע להקשר לגבי מנעולים מוחזקים, מצב RCS וגורמים אחרים. צריך להגדיר את ה-hook בקובץ הכותרת בספרייה include/trace/hooks.

לדוגמה, הקוד הבא מציג הצהרה אפשרית עבור trace_android_vh_sched_exit() בקובץ 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>

כדי ליצור את הממשקים הנדרשים ל-hook של הספק, מוסיפים את קובץ הכותרת עם הצהרת ה-hook אל drivers/android/vendor_hooks.c ומיצאים את הסמלים. לדוגמה, הקוד הבא משלים את ההצהרה על ה-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);

הערה: כדי להבטיח את היציבות של ABI, צריך להגדיר באופן מלא את מבני הנתונים שבהם נעשה שימוש בהצהרת ה-hook. אחרת, לא בטוח לבצע הסרה של הפניה (dereference) של ההפניות האטומות או להשתמש ב-struct בהקשרים עם גודל. הקטע include שמספק את ההגדרה המלאה של מבני הנתונים האלה צריך להופיע בקטע #ifndef __GENKSYMS__ של drivers/android/vendor_hooks.c. קובצי הכותרות ב-include/trace/hooks לא צריכים לכלול את קובץ הכותרת של הליבה עם הגדרות הטיפוסים, כדי למנוע שינויים ב-CRC שגורמים לשיבושים ב-KMI. במקום זאת, צריך להצהיר על הסוגים.

צירוף ל-hooks של ספקים

כדי להשתמש ב-hooks של ספקים, מודול הספק צריך לרשום טיפול ב-hook (בדרך כלל במהלך האינטוליזציה של המודול). לדוגמה, הקוד הבא מציג את הטיפול במודול foo.ko עבור 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);
    ...
}

שימוש ב-hooks של ספקים מקובצי כותרות

כדי להשתמש ב-vendor hooks מקובצי כותרות, יכול להיות שתצטרכו לעדכן את קובץ הכותרת של ה-vendor hook כדי לבטל את ההגדרה של TRACE_INCLUDE_PATH, כדי למנוע שגיאות build שמציינות שלא ניתן למצוא קובץ כותרת של נקודת מעקב. לדוגמה,

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.

כדי לתקן שגיאה מסוג build, צריך להחיל את התיקון המקביל על קובץ הכותרת של ה-hook של הספק שכלול. מידע נוסף זמין בכתובת 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

הגדרת UNDEF_TRACE_INCLUDE_PATH מורה ל-include/trace/define_trace.h לבטל את ההגדרה של TRACE_INCLUDE_PATH אחרי יצירת נקודות המעקב.

תכונות הליבה המרכזיות

אם אף אחת מהשיטות הקודמות לא מאפשרת לכם להטמיע תכונה ממארז, עליכם להוסיף את התכונה כשינוי ספציפי ל-Android לליבה של הליבה. כדי להתחיל את השיחה, צריך ליצור דיווח על בעיה במעקב הבעיות (IT).

ממשק תכנות של משתמש באפליקציה (UAPI)

קובצי כותרות של UAPI שינויים בקובצי הכותרות של UAPI חייבים להתרחש בחלק העליון של זרם הנתונים, אלא אם מדובר בשינויים בממשקים ספציפיים ל-Android. שימוש בקובצי כותרת ספציפיים לספק כדי להגדיר ממשקים בין מודולים של ספקים לבין קוד של שטח משתמש של ספקים.
צומתי sysfs אסור להוסיף צמתים חדשים של sysfs לליבה של GKI (תוספות כאלה תקפות רק במודולים של ספקים). אפשר לשנות צמתים של sysfs שמשמשים את הספריות והקוד ב-Java שמרכיבים את מסגרת Android, שהם לא תלויים ב-SoC ובמכשיר, רק בדרכים תואמות, וצריך לשנות אותם ב-upstream אם הם לא צמתים ספציפיים ל-Android. אפשר ליצור צמתים sysfs ספציפיים לספק לשימוש במרחב המשתמש של הספק. כברירת מחדל, הגישה לצמתים של sysfs על ידי מרחב המשתמש נדחית באמצעות SELinux. על הספק להוסיף את תוויות SELinux המתאימות כדי לאפשר גישה לתוכנה מורשית של הספק.
צמתים של DebugFS מודולים של ספקים יכולים להגדיר צמתים ב-debugfs לצורך ניפוי באגים בלבד (כי debugfs לא מותקן במהלך הפעולה הרגילה של המכשיר).

פיתוח קוד ליבה ל-GKI קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.