הגבלות על ממשקים שאינם SDK

החל מ-Android 9 (רמת API 28), הפלטפורמה מגבילה את הממשקים שאינם SDK שבהם האפליקציה יכולה להשתמש. ההגבלות האלה חלות בכל פעם שאפליקציה מפנה לממשק שאינו ב-SDK או מנסה לקבל את ה-handle שלו באמצעות שיקוף או JNI. ההגבלות האלה הוטמעו כדי לשפר את חוויית המשתמש והמפתח, ולצמצם את הסיכון לקריסות אצל המשתמשים ולשדרוגים דחופים אצל המפתחים. מידע נוסף על ההחלטה הזו זמין במאמר שיפור היציבות על ידי צמצום השימוש בממשקים שאינם SDK.

הבחנה בין ממשקי SDK לממשקים שאינם SDK

באופן כללי, ממשקי SDK ציבוריים הם אלה שמתועדים בחבילת המדדים של מסגרת Android. הטיפול בממשקים שאינם SDK הוא פרט הטמעה ש-API מבודד ממנו, ולכן הממשקים האלה כפופים לשינויים ללא הודעה מוקדמת.

כדי למנוע קריסות והתנהגות בלתי צפויה, באפליקציות צריך להשתמש רק בחלקים הרשמית מתועדים של הכיתות ב-SDK. המשמעות היא גם שאסור לגשת לשיטות או לשדות שלא מפורטים ב-SDK כשאתם יוצרים אינטראקציה עם כיתה באמצעות מנגנונים כמו רפלקציה.

רשימות של ממשקי API שאינם SDK

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

כדי למזער את ההשפעה של ההגבלות על ממשקים שאינם SDK על תהליך הפיתוח, הממשקים שאינם SDK מחולקים לרשימות שמגדירות את מידת ההגבלה על השימוש בהם, בהתאם לרמת ה-API שאליו כוון השימוש. בטבלה הבאה מתוארות כל אחת מהרשימות האלה:

רשימה תגי קוד תיאור
רשימת חסימה
  • blocked
  • הוצאה משימוש: blacklist
 ממשקים שאינם SDK, שאי אפשר להשתמש בהם ללא קשר לרמת ה-API לטירגוט של האפליקציה. אם האפליקציה תנסה לגשת לאחד מהממשקים האלה, המערכת תשליך שגיאה.
חסום באופן מותנה
  • max-target-x
  • הוצאה משימוש: greylist-max-x

החל מ-Android 9 (רמת API 28), לכל רמת API יש ממשקים שאינם SDK, והם מוגבלים כשאפליקציה מטרגטת לרמת ה-API הזו.

הרשימות האלה מסומנות לפי רמת ה-API המקסימלית (max-target-x) שאפליקציה יכולה לטרגט לפני שהאפליקציה לא תהיה מסוגלת יותר לגשת לממשקים שאינם SDK שמופיעים ברשימה הזו. לדוגמה, ממשק שאינו SDK שלא נחסם ב-Android Pie אבל חסום עכשיו ב-Android 10 נכלל ברשימה max-target-p‏ (greylist-max-p), כאשר האות 'p' מייצגת את Pie או Android 9‏ (API ברמה 28).

אם האפליקציה מנסה לגשת לממשק שמוגבל לרמת ה-API לטירגוט, המערכת תתנהג כאילו ה-API נמצא ברשימת החסימות.
המכשיר לא נתמך
  • unsupported
  • הוצאה משימוש: greylist
 ממשקים שאינם SDK ללא הגבלות, שבהם האפליקציה שלכם יכולה להשתמש. עם זאת, חשוב לזכור שהממשקים האלה לא נתמכים ועשויים להשתנות ללא הודעה מוקדמת. צפוי שהממשקים האלה ייחסמו באופן מותנה בגרסאות עתידיות של Android ברשימה max-target-x.
SDK
  • גם public-api וגם sdk
  • הוצא משימוש: גם public-api וגם whitelist
 ממשקים שאפשר להשתמש בהם באופן חופשי ועכשיו נתמכים כחלק ממסגרת Android הרשמית, Package Index.
ממשקי API לבדיקה
  • test-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 16 (תצוגה מקדימה למפתחים)

לגרסה Android 16, אפשר להוריד את הקובץ הבא שמתאר את כל הממשקים שאינם SDK ואת הרשימות התואמות שלהם:

קובץ: hiddenapi-flags.csv

סיכום ביקורת (checksum) מסוג SHA-256: a22d5c2fa9c24ec0b864f0680208e9794222d1921114abe3245979143ce6d1c6

מידע נוסף על השינויים ברשימת ממשקי ה-API שאינם SDK ב-Android 16 זמין במאמר עדכונים בהגבלות על ממשקים שאינם SDK ב-Android 16.

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 ציבוריים לממשקי 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 thrown
השתקפות באמצעות Class.getDeclaredField() או Class.getField() NoSuchFieldException thrown
השתקפות באמצעות 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, אפשר לקבל קריאה חוזרת לכל שימוש בממשק שאינו 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 ולבצע את השלבים הבאים:

  1. מורידים את הכלי Veridex מהמאגר של גרסת build מוכנה מראש של Android Runtime.
  2. מחלצים את התוכן של הקובץ appcompat.tar.gz.
  3. בתיקייה שחולצה, מאתרים את הקובץ veridex-linux.zip ומחלצים אותו.

  4. עוברים לתיקייה ללא הדחיסה ומריצים את הפקודה הבאה, כאשר your-app.apk הוא קובץ ה-APK שרוצים לבדוק:

    ./appcompat.sh --dex-file=your-app.apk

macOS

כדי להפעיל את הכלי Veridex ב-macOS:

  1. מורידים את הכלי Veridex מהמאגר של גרסת build מוכנה מראש של Android Runtime.
  2. מחלצים את התוכן של הקובץ appcompat.tar.gz.
  3. בתיקייה שחולצה, מאתרים את הקובץ veridex-mac.zip ומחלצים אותו.

  4. עוברים לתיקייה ללא הארכיון ומריצים את הפקודה הבאה, כאשר /path-from-root/your-app.apk הוא הנתיב לקובץ ה-APK שרוצים לבדוק, החל מתיקיית השורש של המערכת:

    ./appcompat.sh --dex-file=/path-from-root/your-app.apk

Linux

כדי להריץ את הכלי Veridex ב-Linux:

  1. מורידים את הכלי Veridex מהמאגר של גרסת build מוכנה מראש של Android Runtime.
  2. מחלצים את התוכן של הקובץ appcompat.tar.gz.
  3. בתיקייה שחולצה, מאתרים את הקובץ veridex-linux.zip ומחלצים אותו.

  4. עוברים לתיקייה ללא הדחיסה ומריצים את הפקודה הבאה, כאשר 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 בתמונת המערכת?

הם מקודדים בביטים של דגל הגישה לשדה ולשיטה בקובצי dex של הפלטפורמה. אין קובץ נפרד בתמונת המערכת שמכיל את הרשימות האלה.

האם הרשימות של ממשקי ה-API שאינם SDK זהות במכשירי OEM שונים עם אותן גרסאות Android?

יצרני ציוד מקורי יכולים להוסיף ממשקים משלהם לרשימת החסימה (רשימת השחור), אבל הם לא יכולים להסיר ממשקים מרשימות ה-API של AOSP שאינן SDK. ה-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).