החל מ-Android 9 (רמת API 28), הפלטפורמה מגבילה את הממשקים שאינם SDK שבהם האפליקציה יכולה להשתמש. ההגבלות האלה חלות בכל פעם שאפליקציה מפנה לממשק שאינו ב-SDK או מנסה לקבל את ה-handle שלו באמצעות שיקוף או JNI. ההגבלות האלה הוטמעו כדי לשפר את חוויית המשתמש והמפתח, ולצמצם את הסיכון לקריסות אצל המשתמשים ולשדרוגים דחופים אצל המפתחים. מידע נוסף על ההחלטה הזו זמין במאמר שיפור היציבות על ידי צמצום השימוש בממשקים שאינם SDK.
הבחנה בין ממשקי SDK לממשקים שאינם SDK
באופן כללי, ממשקי SDK ציבוריים הם ממשקי ה-SDK המתועדים ב-Package Index של מסגרת Android. הטיפול בממשקים שאינם SDK הוא פרטי הטמעה שה-API מופשט, ולכן הממשקים האלה כפופים לשינויים ללא הודעה מוקדמת.
כדי למנוע קריסות והתנהגות בלתי צפויה, אפליקציות צריכות להשתמש רק בחלקים של המחלקות המתועדים באופן רשמי ב-SDK. המשמעות היא גם שאסור לגשת לשיטות או לשדות שלא רשומים ב-SDK כשיש לכם אינטראקציה עם כיתה באמצעות מנגנונים כמו השתקפות.
רשימות של ממשקי API שאינם SDK
בכל גרסה של Android, אנחנו מגבילים עוד ממשקים שאינם SDK. אנחנו יודעים שהמגבלות האלה יכולות להשפיע על תהליך הפיתוח וההשקה שלכם, ואנחנו רוצים לוודא שיש לכם את הכלים לזהות שימוש בממשקים שאינם SDK, הזדמנות לשלוח לנו משוב וזמן לתכנן ולהתאים את עצמכם למדיניות החדשה.
כדי למזער את ההשפעה של ההגבלות על ממשקים שאינם SDK על תהליך הפיתוח, הממשקים שאינם SDK מחולקים לרשימות שמגדירות את מידת ההגבלה על השימוש בהם, בהתאם לרמת ה-API שאליו כוון השימוש. בטבלה הבאה מתוארות כל אחת מהרשימות האלה:
רשימה | תגי קוד | תיאור |
---|---|---|
רשימת חסימה |
|
ממשקים שאינם SDK, שאי אפשר להשתמש בהם ללא קשר לרמת ה-API לטירגוט של האפליקציה. אם האפליקציה מנסה לגשת לאחד מהממשקים האלה, המערכת תבצע שגיאה. |
חסום באופן מותנה |
|
החל מ-Android 9 (רמת API 28), לכל רמת API יש ממשקים שאינם SDK שמוגבלים כאשר אפליקציה מטרגטת את רמת ה-API הזו. הרשימות האלה מסומנות לפי רמת ה-API המקסימלית ( אם האפליקציה מנסה לגשת לממשק שמוגבל לרמת ה-API לטירגוט, המערכת תתנהג כאילו ה-API נמצא ברשימת החסימות. |
המכשיר לא נתמך |
|
ממשקים שאינם SDK ללא הגבלות, שבהם האפליקציה שלכם יכולה להשתמש. עם זאת, חשוב לזכור שהממשקים האלה לא נתמכים ועשויים להשתנות ללא הודעה מוקדמת. בגרסאות עתידיות של Android יש סיכוי גבוה שהממשקים האלה ייחסמו ברשימה max-target-x . |
SDK |
|
ממשקים שאפשר להשתמש בהם בחינם ונתמכים עכשיו כחלק מאינדקס החבילות שמתועד באופן רשמי של Android. |
ממשקי API לבדיקה |
|
ממשקים המשמשים לבדיקות פנימיות של מערכות, כמו ממשקי API שמאפשרים לבצע בדיקות באמצעות Compatibility Test Suite (CTS). ממשקי ה-API לבדיקה לא נכללים ב-SDK. החל מ-Android 11 (רמת API 30), ממשקי API לבדיקה נכללים ברשימת החסימות, ולכן אפליקציות לא יכולות להשתמש בהם ללא קשר לרמת ה-API לטירגוט שלהן. כל ממשקי ה-API לבדיקה לא נתמכים ועשויים להשתנות ללא הודעה מראש, ללא קשר לרמת ה-API של הפלטפורמה. |
אפשר להשתמש בממשקים מסוימים שאינם ב-SDK (בהתאם לרמת ה-API לטירגוט של האפליקציה), אבל שימוש בשדה או בשיטה שלא נכללים ב-SDK תמיד כרוך בסיכון גבוה להפרעה באפליקציה. אם האפליקציה שלכם מסתמכת על ממשקים שאינם ב-SDK, כדאי להתחיל לתכנן את המעבר לממשקי SDK או לחלופות אחרות. אם לא מצאתם חלופה לשימוש בממשק שאינו ב-SDK עבור תכונה באפליקציה, עליכם לבקש ממשק API ציבורי חדש.
איך בודקים לאיזו רשימה שייך ממשק
הרשימות של ממשקים שאינם ב-SDK נוצרות כחלק מהפלטפורמה. בסעיפים הבאים מפורט מידע על כל גרסה של Android.
Android 15
לגרסה Android 15 (רמת API 35), אפשר להוריד את הקובץ הבא שמתאר את כל הממשקים שאינם SDK ואת הרשימות התואמות שלהם:
קובץ: hiddenapi-flags.csv
סיכום ביקורת (checksum) מסוג SHA-256:
40134e205e58922a708c453726b279a296e6a1f34a988abd90cec0f3432ea5a9
מידע נוסף על השינויים ברשימת ה-API שאינו SDK ב-Android 15 זמין במאמר עדכונים לגבי הגבלות על ממשקים שאינם SDK ב-Android 15.
Android 14
ל-Android 14 (רמת API 34), תוכלו להוריד את הקובץ הבא עם תיאור של כל הממשקים שהם לא SDK והרשימות התואמות שלהם:
קובץ: hiddenapi-flags.csv
סיכום ביקורת (checksum) מסוג SHA-256:
7e00db074cbe51c51ff4b411f7b48e98692951395c5c17d069c822cc1d0eae0f
מידע נוסף על השינויים ברשימת ממשקי ה-API שאינם SDK ב-Android 14 זמין במאמר עדכונים בהגבלות על ממשקים שאינם SDK ב-Android 14.
Android 13
לגרסה Android 13 (רמת API 33), אפשר להוריד את הקובץ הבא שמתאר את כל הממשקים שאינם SDK ואת הרשימות התואמות שלהם:
קובץ: hiddenapi-flags.csv
סיכום ביקורת (checksum) מסוג SHA-256:
233a277aa8ac475b6df61bffd95665d86aac6eb2ad187b90bf42a98f5f2a11a3
לקבלת מידע נוסף על השינויים ברשימה של ממשקי API שאינם SDK ב-Android 13, כולל הצעות לחלופות API ציבוריות שחסומים באופן מותנה ב-Android 13, ראו עדכונים להגבלות בממשק שאינו SDK ב-Android 13.
12 Android
לגבי Android 12 (רמת API 31), אפשר להוריד את הקובץ הבא שמתאר את כל הממשקים שאינם SDK ואת הרשימות התואמות שלהם:
קובץ: hiddenapi-flags.csv
סיכום ביקורת (checksum) מסוג SHA-256:
40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761
מידע נוסף על השינויים ברשימת ממשקי ה-API שאינם SDK ב-Android 12, כולל הצעות לחלופות של ממשקי API ציבוריים לממשקי API שחוסמים באופן מותנה ב-Android 12, זמין במאמר שינויים ברשימת ממשקי ה-API ב-Android 12.
Android 11
לגרסה Android 11 (רמת API 30), אפשר להוריד את הקובץ הבא שמתאר את כל הממשקים שאינם SDK ואת הרשימות התואמות שלהם:
קובץ: hiddenapi-flags.csv
סיכום ביקורת (checksum) מסוג SHA-256:
a19d839f4f61dc9c94960ae977b2e0f3eb30f880ba1ffe5108e790010b477a56
מידע נוסף על השינויים ברשימת ממשקי ה-API שאינם SDK ב-Android 11, כולל הצעות לחלופות לממשקי API ציבוריים לממשקי API שחוסמים באופן מותנה ב-Android 11, זמין במאמר שינויים ברשימת ממשקי ה-API ב-Android 11.
Android 10
לגרסה Android 10 (רמת API 29), אפשר להוריד את הקובץ הבא שמתאר את כל הממשקים שאינם SDK ואת הרשימות התואמות שלהם:
קובץ: hiddenapi-flags.csv
סיכום ביקורת (checksum) מסוג SHA-256:
f22a59c215e752777a114bd9b07b0b6b4aedfc8e49e6efca0f99681771c5bfeb
מידע נוסף על השינויים ברשימת ממשקי ה-API שאינם SDK ב-Android 10, כולל הצעות לחלופות לממשקי API ציבוריים לממשקי API שחוסמים באופן מותנה ב-Android 10, זמין במאמר שינויים ברשימת ממשקי ה-API ב-Android 10.
Android 9
ב-Android 9 (רמת API 28), קובץ הטקסט הבא מכיל את רשימת ממשקי ה-API שאינם SDK ושאינם מוגבלים (ברשימת ההיתרים): hiddenapi-light-greylist.txt
.
רשימת החסימה (blacklist
) והרשימה של ממשקי ה-API החסומים באופן מותנה (רשימה כהה) נוצרים בזמן ה-build.
יצירת רשימות מ-AOSP
כשעובדים עם AOSP, אפשר ליצור קובץ hiddenapi-flags.csv
שמכיל את כל הממשקים שאינם SDK ואת הרשימות התואמות שלהם. כדי לעשות זאת, מורידים את המקור של AOSP ומריצים את הפקודה הבאה:
m out/soong/hiddenapi/hiddenapi-flags.csv
לאחר מכן, הקובץ יופיע במיקום הבא:
out/soong/hiddenapi/hiddenapi-flags.csv
ההתנהגות הצפויה כשמתבצעת גישה לממשקים מוגבלים שאינם SDK
בטבלה הבאה מתוארת ההתנהגות הצפויה בזמן שהאפליקציה מנסה לגשת לממשק שאינו SDK שנכלל ברשימת החסימה.
אמצעי הגישה | התוצאה |
---|---|
הוראה של Dalvik שמפנה לשדה | NoSuchFieldError thrown |
הוראה של Dalvik שמתייחסת לשיטה | זריקה של NoSuchMethodError |
השתקפות באמצעות Class.getDeclaredField() או Class.getField() |
זריקה של NoSuchFieldException |
השתקפות באמצעות Class.getDeclaredMethod() , Class.getMethod() |
NoSuchMethodException thrown |
השתקפות באמצעות Class.getDeclaredFields() , Class.getFields() |
חברים שלא משתמשים ב-SDK לא מופיעים בתוצאות |
השתקפות באמצעות Class.getDeclaredMethods() , Class.getMethods() |
חברים שלא משתמשים ב-SDK לא מופיעים בתוצאות |
JNI באמצעות env->GetFieldID() |
NULL הוחזר, NoSuchFieldError הוטח |
JNI באמצעות env->GetMethodID() |
NULL הוחזרו, הוקצו NoSuchMethodError |
בדיקת האפליקציה לזיהוי ממשקים שאינם SDK
יש כמה שיטות לבדיקת ממשקים שאינם SDK באפליקציה.
בדיקה באמצעות אפליקציה שניתן לנפות בה באגים
כדי לבדוק ממשקים שאינם ב-SDK, אפשר ליצור ולהריץ אפליקציה שניתן לנפות באגים במכשיר או באמולטור עם Android 9 (רמת API 28) ואילך. חשוב לוודא שהמכשיר או הסימולטור שבהם אתם משתמשים תואמים לרמת ה-API לטירגוט של האפליקציה.
במהלך בדיקות האפליקציה, המערכת מדפיסה הודעת יומן אם האפליקציה ניגשת לממשקים מסוימים שאינם SDK. תוכלו לבדוק את הודעות היומן של האפליקציה כדי לראות את הפרטים הבאים:
- הכיתה, השם והסוג של המוצהר (בפורמט שבו נעשה שימוש בסביבת זמן הריצה של Android).
- אמצעי הגישה: קישור, שימוש בהשתקפות או שימוש ב-JNI.
- הרשימה שאליה הממשק שאינו ב-SDK שייך.
אפשר להשתמש ב-adb logcat
כדי לגשת להודעות היומן האלה, שמופיעות מתחת למזהה ה-PID של האפליקציה שפועלת. לדוגמה, רשומה ביומן עשויה להיראות כך:
Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI)
בדיקה באמצעות StrictMode API
אפשר גם לבדוק ממשקים שאינם SDK באמצעות ה-API StrictMode
. כדי להפעיל את האפשרות הזו, משתמשים ב-method detectNonSdkApiUsage
. אחרי שמפעילים את ה-API StrictMode
, אפשר לקבל קריאה חוזרת (callback) בכל שימוש בממשק שאינו SDK באמצעות penaltyListener
, שבו אפשר להטמיע טיפול מותאם אישית. האובייקט Violation
שסופק בקריאה החוזרת נגזר מ-Throwable
, ודוח הקריסות המצורף מספק את ההקשר של השימוש.
בדיקה באמצעות הכלי veridex
אפשר גם להריץ את כלי הניתוח הסטטי של Veridex על קובץ ה-APK. כלי Veridex סורק את כל קוד האפליקציה ב-APK, כולל ספריות של צד שלישי, ומדווח על כל שימוש בממשקים שאינם SDK שהוא מוצא.
המגבלות של הכלי Veridex כוללות את הדברים הבאים:
- הוא לא יכול לזהות קריאות דרך JNI.
- היא יכולה לזהות רק קבוצת משנה של קריאות באמצעות רפלקציה.
- הניתוח של נתיבי הקוד הלא פעילים מוגבל לבדיקות ברמת ה-API.
- אפשר להריץ אותו רק במכונות שתומכות בהוראות SSE4.2 ו-POPCNT.
Windows
לא מוצעות תוכניות בינאריות מקוריות ל-Windows, אבל אפשר להריץ את הכלי veridex ב-Windows על ידי הפעלת התוכניות הבינאריות של Linux באמצעות Windows Subsystem for Linux (WSL). לפני שמבצעים את השלבים בקטע הזה, צריך להתקין את WSL ולבחור ב-Ubuntu כחלוקת Linux.
אחרי שמתקינים את Ubuntu, פותחים טרמינל Ubuntu ומבצעים את השלבים הבאים:
- מורידים את הכלי Veridex מהמאגר המובנה מראש של Android זמן ריצה.
- מחלצים את התוכן של הקובץ
appcompat.tar.gz
. - בתיקייה שחולצה, מאתרים את הקובץ
veridex-linux.zip
ומחלצים אותו. עוברים לתיקיית ה-ZIP ומריצים את הפקודה הבאה, שבה
your-app.apk
הוא ה-APK שרוצים לבדוק:./appcompat.sh --dex-file=your-app.apk
macOS
כדי להפעיל את הכלי Veridex ב-macOS:
- מורידים את הכלי Veridex מהמאגר של גרסת build מוכנה מראש של Android Runtime.
- מחלצים את התוכן של הקובץ
appcompat.tar.gz
. - בתיקייה שחולצה, מאתרים את הקובץ
veridex-mac.zip
ומחלצים אותו. עוברים לתיקייה ללא הארכיון ומריצים את הפקודה הבאה, כאשר
/path-from-root/your-app.apk
הוא הנתיב לקובץ ה-APK שרוצים לבדוק, החל מתיקיית השורש של המערכת:./appcompat.sh --dex-file=/path-from-root/your-app.apk
Linux
כדי להריץ את הכלי Veridex ב-Linux:
- מורידים את הכלי Veridex מהמאגר של גרסת build מוכנה מראש של Android Runtime.
- מחלצים את התוכן של הקובץ
appcompat.tar.gz
. - בתיקייה שחולצה, מאתרים את הקובץ
veridex-linux.zip
ומחלצים אותו. עוברים לתיקייה ללא הדחיסה ומריצים את הפקודה הבאה, כאשר
your-app.apk
הוא קובץ ה-APK שרוצים לבדוק:./appcompat.sh --dex-file=your-app.apk
בדיקה באמצעות הכלי לזיהוי שגיאות בקוד ב-Android Studio
בכל פעם שאתם יוצרים את האפליקציה ב-Android Studio, כלי ה-lint בודק את הקוד כדי לאתר בעיות פוטנציאליות. אם באפליקציה שלכם נעשה שימוש בממשקים שאינם SDK, יכול להיות שיופיעו שגיאות או אזהרות שקשורות לגרסאות build, בהתאם לרשימה שאליה הממשקים האלה שייכים.
אפשר גם להפעיל את הכלי לאיתור שגיאות בקוד משורת הפקודה או להפעיל ביקורות באופן ידני בפרויקט, בתיקייה או בקובץ ספציפיים.
בדיקה באמצעות Play Console
כשאתם מעלים את האפליקציה למסלול הפצה לבדיקה ב-Play Console, האפליקציה נבדקת באופן אוטומטי כדי לאתר בעיות פוטנציאליות, ונוצר דוח טרום-השקה. אם האפליקציה משתמשת בממשקים שאינם ב-SDK, תופיע שגיאה או אזהרה בדוח שלפני ההשקה, בהתאם לרשימת הממשקים האלה.
מידע נוסף זמין בקטע 'תאימות ל-Android' במאמר שימוש בדוחות לפני ההשקה לזיהוי בעיות.
שליחת בקשה ל-API ציבורי חדש
אם לא מצאתם חלופה לשימוש בממשק שאינו ב-SDK עבור תכונה באפליקציה, תוכלו לבקש ממשק API ציבורי חדש על ידי יצירת בקשה להוספת תכונה במעקב הבעיות שלנו.
כשיוצרים בקשה להוספת תכונה, צריך לציין את הפרטים הבאים:
- ממשק ה-API שאינו נתמך שבו אתם משתמשים, כולל התיאור המלא שמופיע בהודעה
Accessing hidden ...
ב-logcat. - למה צריך להשתמש בממשקי ה-API האלה, כולל פרטים על התכונה ברמה הכללית שה-API נדרש בשבילה, ולא רק פרטים ברמה נמוכה.
- למה ממשקי ה-API הציבוריים של SDK הרלוונטיים לא מספיקים למטרות שלכם.
- אפשרויות חלופיות אחרות שניסיתם, ומדוע הן לא עבדו.
כשתספקו את הפרטים האלה בבקשה להוספת תכונה, תגדילו את הסיכוי לקבלת ממשק API ציבורי חדש.
שאלות נוספות
בקטע הזה ריכזנו תשובות לשאלות נוספות שמפתחים שואלים לעיתים קרובות:
שאלות כלליות
איך Google יכולה לוודא שהיא יכולה לתעד את הצרכים של כל האפליקציות באמצעות הכלי למעקב אחר בעיות?
יצרנו את הרשימות הראשוניות ל-Android 9 (רמת API 28) באמצעות ניתוח סטטי של אפליקציות, שהושלמה באמצעות השיטות הבאות:
- בדיקה ידנית של האפליקציות המובילות ב-Play ובפלטפורמות אחרות
- דוחות פנימיים
- איסוף נתונים אוטומטי ממשתמשים פנימיים
- דוחות תצוגה מקדימה למפתחים
- ניתוח סטטי נוסף שתוכנן לכלול באופן שמרני יותר תוצאות חיוביות שגויות
כשאנחנו בודקים את הרשימות לכל גרסה חדשה, אנחנו מביאים בחשבון את השימוש ב-API וגם את המשוב של המפתחים באמצעות הכלי למעקב אחר בעיות.
איך מאפשרים גישה לממשקים שאינם SDK?
כדי להפעיל גישה לממשקים שאינם ב-SDK במכשירי פיתוח, משנים את מדיניות האכיפה של ה-API באמצעות פקודות adb. הפקודות שבהן משתמשים משתנות בהתאם לרמת ה-API. כדי להשתמש בפקודות האלה, לא צריך מכשיר עם הרשאות בסיס.
- Android מגרסה 10 (API ברמה 29) ואילך
כדי להפעיל את הגישה, צריך להשתמש ברכיב adb הבא
פקודה:
adb shell settings put global hidden_api_policy 1
כדי לאפס את מדיניות האכיפה של ה-API להגדרות ברירת המחדל, משתמשים בפקודה הבאה:
adb shell settings delete global hidden_api_policy
- Android 9 (רמת API 28)
כדי להפעיל את הגישה, משתמשים בפקודות adb הבאות:
adb shell settings put global hidden_api_policy_pre_p_apps 1
adb shell settings put global hidden_api_policy_p_apps 1
כדי לאפס את מדיניות האכיפה של ה-API להגדרות ברירת המחדל, משתמשים בפקודות הבאות:
adb shell settings delete global hidden_api_policy_pre_p_apps
adb shell settings delete global hidden_api_policy_p_apps
אפשר להגדיר את המספר השלם במדיניות האכיפה של ה-API לאחד מהערכים הבאים:
- 0: השבתת כל הזיהוי של ממשקים שאינם SDK. השימוש בהגדרה הזו משבית את כל הודעות היומן לשימוש בממשק שאינו SDK, ומונע מכם לבדוק את האפליקציה באמצעות ה-API של
StrictMode
. לא מומלץ להשתמש בהגדרה הזו. - 1: הפעלת גישה לכל הממשקים שאינם SDK, אבל הדפסת הודעות יומן עם אזהרות לכל שימוש בממשק שאינו SDK. בעזרת ההגדרה הזו תוכלו גם לבדוק את האפליקציה באמצעות ה-API של
StrictMode
. - 2: איסור השימוש בממשקים שאינם ב-SDK ששייכים לרשימת החסימות או חסומים באופן מותנה עבור רמת ה-API לטירגוט.
שאלות על רשימות של ממשקים שאינם SDK
איפה אפשר למצוא את רשימות ה-API שאינן SDK בתמונת המערכת?
הם מקודדים בביטים של דגלי גישה בשדה ובשיטה בקובצי Platform dex. אין קובץ נפרד בתמונת המערכת שמכיל את הרשימות האלה.
האם הרשימות של ממשקי ה-API שאינם SDK זהות במכשירי OEM שונים עם אותן גרסאות Android?
יצרני ציוד מקורי יכולים להוסיף ממשקים משלהם לרשימת החסימה (רשימה שחורה), אבל הם לא יכולים להסיר ממשקים מרשימות של ממשקי API שאינם SDK ב-AOSP. ה-CDD מונע שינויים כאלה, ובדיקות CTS מוודאות שמערכת Android Runtime אוכפת את הרשימה.
שאלות לגבי התאימות של אפליקציות קשורות
האם יש הגבלות על ממשקים שאינם NDK בקוד מקורי?
Android SDK כולל ממשקי Java. הפלטפורמה התחילה להגביל את הגישה לממשקים שאינם מסוג NDK בשביל קוד C/C++ מקורי ב-Android 7 (רמת API 26). מידע נוסף זמין במאמר שיפור היציבות באמצעות הגבלות על סמלים פרטיים של C/C++ ב-Android N.
האם יש תוכנית להגבלת dex2oat או מניפולציה של קובצי DEX?
אין לנו תוכניות פעילות להגבלת הגישה לקובץ הבינארי dex2oat, אבל אנחנו לא מתכוונים לאפשר לפורמט קובץ ה-DEX להיות יציב או ממשק ציבורי מעבר לחלקים שצוינו באופן ציבורי בפורמט Dalvik Executable. אנחנו שומרים לעצמנו את הזכות לשנות או לבטל את dex2oat ואת החלקים הלא ספציפיים של פורמט ה-DEX בכל שלב. חשוב גם לזכור שקבצים נגזרים שנוצרו על ידי dex2oat, כמו ODEX (שנקרא גם OAT), VDEX ו-CDEX, הם כולם פורמטים לא מוגדרים.
מה קורה אם ערכת SDK קריטית של צד שלישי (למשל, כלי לטשטוש קוד) לא יכולה להימנע משימוש בממשקים שאינם SDK, אבל מתחייבת לשמור על תאימות לגרסאות עתידיות של Android? האם Android יכולה לוותר על דרישות התאימות במקרה הזה?
אין לנו כוונה לבטל את דרישות התאימות לפי SDK. אם מפתחי SDK יכולים לשמור על תאימות רק על ידי שימוש בממשקים שמופיעים ברשימות הלא נתמכות (לשעבר האפורות), הם צריכים להתחיל לתכנן את המעבר לממשקי SDK או לחלופות אחרות, ולבקש ממשק API ציבורי חדש בכל פעם שהם לא מוצאים חלופה לשימוש בממשק שאינו ב-SDK.
האם הגבלות על ממשק שאינו SDK חלות על כל האפליקציות, כולל אפליקציות מערכת ואפליקציות צד ראשון, לא רק על אפליקציות צד שלישי?
כן, אבל אנחנו מחריגים אפליקציות שנחתמו באמצעות מפתח הפלטפורמה ואפליקציות מסוימות של קובצי אימג' של מערכת. חשוב לדעת שההחרגות האלה חלות רק על אפליקציות שנכללות בקובץ האימג' של המערכת (או על אפליקציות בקובץ אימג' מעודכן של המערכת). הרשימה מיועדת רק לאפליקציות שמבוססות על ממשקי ה-API הפרטיים של הפלטפורמה, ולא על ממשקי ה-API של ה-SDK (כאשר LOCAL_PRIVATE_PLATFORM_APIS := true
).