סקירה כללית על זמן הריצה ל-SDK

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

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

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

• סביבת הפעלה שעברה שינוי
• הרשאות וזכויות גישה מוגדרות היטב לנתונים עבור ערכות ה-SDK

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

יעדים

ההצעה הזו נועדה להשיג את המטרות הבאות:

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

ערכות SDK פועלות בתהליך מבודד

זמן הריצה ל-SDK מאפשר לערכות SDK תואמות – שנקראות בהמשך המסמך הזה ערכות SDK תואמות זמן ריצה (RE) – לפעול בתהליך נפרד מהאפליקציה. הפלטפורמה מאפשרת תקשורת דו-כיוונית בין התהליך של האפליקציה לבין זמן הריצה ל-SDK. פרטים נוספים מופיעים בקטע 'תקשורת' במסמך הזה. ערכות SDK שאינן RE יישארו בתהליך של האפליקציה כמו היום. התרשימים הבאים ממחישים את השינויים האלה:

מודל הפצה מהימן חדש לערכות SDK

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

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

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

התהליך כולל את השלבים הבאים:

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

מנגנון ההפצה החדש הזה מאפשר עדכונים עצמאיים של ערכות SDK בתנאים הבאים:

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

ההטמעה של היכולות האלה תלויה בחנות.

בתרשימים הבאים מוצגים השינויים המוצעים בהפצה של ה-SDK:

---

שינויים באופן שבו ערכות SDK ואפליקציות נוצרות, מופעלות ומופצות

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

• גישה: הרשאות, זיכרון, אחסון
• ביצוע: שפות, שינויים בזמן ריצה, מחזור חיים, עיבוד מדיה
• תקשורת: תקשורת בין האפליקציה ל-SDK ותקשורת בין SDK ל-SDK
• פיתוח: איך לבצע build, ניפוי באגים ובדיקה במודל הזה
• הפצה: איך להפיץ, לעדכן ולבטל עדכונים בגרסאות שונות של Android, אפליקציות וערכות SDK

במסמך הזה יש גם שאלות נפוצות עם תשובות לשאלות נפוצות.

זו הצעה ראשונית לעיצוב, ואנחנו מבינים שזה עשוי להיות שינוי משמעותי לחלק מחברי האקוסיסטם. לכן אנחנו מבקשים ממך לשלוח לנו משוב באמצעות כלי המעקב אחר בעיות.

גישה

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

הרשאות SDK

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

• ‫INTERNET: גישה לאינטרנט כדי לתקשר עם שירות אינטרנט.
• ACCESS_NETWORK_STATE: גישה למידע על רשתות.
• ‫READ_BASIC_PHONE_STATE: גישה למידע על מצב הטלפון, למשל סוג הרשת הסלולרית.
• הרשאות גישה לממשקי API לשמירה על פרטיות, שמספקים יכולות פרסום בסיסיות בלי צורך בגישה למזהים בין אפליקציות.
• ‫AD_ID: אפשרות לשלוח בקשה למזהה הפרסום. הגישה להרשאה הזו תהיה מוגבלת גם על ידי האפליקציה.

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

זיכרון

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

אחסון

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

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

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

ביצוע

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

קוד

קוד Android (אפליקציות וערכות SDK) מפוענח בעיקר על ידי Android Runtime‏ (ART), בין אם הקוד נכתב ב-Kotlin או ב-Java. העושר של ART והמבנים הלשוניים שהוא מציע, יחד עם היכולת לאימות שהוא מציע בהשוואה לחלופות – במיוחד קוד מקורי – נראה שיוצרים איזון מתאים בין פונקציונליות לפרטיות. אנחנו מציעים שקוד SDK שמופעל בזמן ריצה יכלול רק בייטקוד של Dex, ולא יתמוך בגישת JNI.

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

SELinux

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

• תהיה גישה לקבוצה מוגבלת של שירותי מערכת. (בשלב העיצוב הפעיל)
• ערכות SDK יוכלו רק לטעון ולהפעיל את הקוד ב-APK שלהן.
• תהיה גישה למערכת למספר מוגבל של מאפיינים. (בשלב העיצוב הפעיל)

ממשקי API

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

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

אפשר לגשת לממשקי API של זמן ריצה ל-SDK רק מאפליקציות שפועלות בחזית. ניסיון לגשת ל-SdkSandboxManagerAPI מאפליקציות ברקע גורם להצגת SecurityException.

לבסוף, אי אפשר להשתמש ב-RE-SDKs בממשקי ה-API של ההתראות כדי לשלוח התראות למשתמשים בכל נקודת זמן.

מחזור חיים

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

• המשתמש או מערכת ההפעלה יכולים להפסיק את האפליקציה. ה-SDK Runtime יופסק אוטומטית מיד לאחר מכן.

• מערכת ההפעלה יכולה להפסיק את זמן הריצה של ה-SDK בגלל עומס על הזיכרון, או בגלל חריגה שלא טופלה ב-SDK, למשל.

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

  ב-Android 14 ואילך, העדיפויות של התהליכים של האפליקציה ושל SDK Runtime זהות. העדיפויות של התהליכים של ActivityManager.RunningAppProcessInfo.importance באפליקציה וב-SDK Runtime צריכות להיות זהות בערך.

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

  • ההצעה כוללת שיטות קריאה חוזרת (callback) שקשורות למחזור החיים של זמן הריצה ל-SDK, כדי שמפתחי אפליקציות יוכלו לזהות מתי זמן הריצה ל-SDK הסתיים.
  • אם SDK Runtime מסתיים בזמן שהמודעות מוצגות, יכול להיות שהמודעות לא יפעלו כצפוי. לדוגמה, יכול להיות שהתצוגות קפאו במסך ולא ניתן יותר ליצור איתן אינטראקציה. האפליקציה יכולה להסיר את הצגת המודעה אם היא לא משפיעה על חוויית המשתמש.
  • האפליקציה יכולה לנסות שוב לטעון את ה-SDK ולבקש מודעות.
  • ב-Android 14, אם זמן הריצה ל-SDK מסתיים בזמן שערכות SDK טעונות, ואם מפתח האפליקציה לא רשם את שיטות הקריאה החוזרת (callback) של מחזור החיים שצוינו למעלה, האפליקציה מסתיימת כברירת מחדל. רק תהליכי האפליקציה שטענו ערכות SDK מסתיימים ויוצאים כרגיל.
  • אובייקטים של Binder שמוחזרים על ידי ה-SDK כדי לתקשר איתו (כמו SandboxedSdk) יוצרים חריגה מסוג DeadObjectException אם האפליקציה משתמשת בהם.

  מודל מחזור החיים הזה עשוי להשתנות בעדכונים עתידיים.

  במקרה של כשלים חוזרים, מפתחי האפליקציה צריכים לתכנן הפחתה חיננית (graceful degradation) בלי ה-SDK, או להודיע למשתמש אם ה-SDK חיוני לפונקציונליות העיקרית של האפליקציה. פרטים נוספים על האינטראקציה בין האפליקציה ל-SDK מופיעים בקטע 'תקשורת' במסמך הזה.

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

מקרים מיוחדים

המקרים הבאים לא נתמכים, ויכול להיות שיובילו להתנהגות לא צפויה:

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

רינדור מדיה

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

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

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

תקינות המערכת

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

תקשורת

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

אפליקציה ל-SDK

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

בהתחשב במבנה של SDK Runtime שמוגבל לתהליך, אנחנו מציעים לבנות שכבת המרה (marshaling) שאפשר לגשת אליה מתוך האפליקציה, כדי להעביר את הקריאות ל-API ואת התגובות או הקריאות החוזרות (callbacks) מעבר לגבול הזה בין האפליקציה לבין ה-SDK. אנחנו מציעים שמפתחי SDK יגדירו את הממשק לשכבת ה-marshaling הזו, והוא ייווצר על ידי כלי בנייה רשמיים בקוד פתוח שאנחנו נפתח.

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

מודל האינטראקציה הכללי ייראה כך:

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

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

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

הגרף באיור הקודם מדגים תקשורת בין אפליקציה ל-SDK ברמה נמוכה יותר, ללא שכבת ה-marshaling.

האפליקציה מתקשרת עם ה-SDK שפועל בתהליך של זמן הריצה ל-SDK באמצעות השלבים הבאים:

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

   קטע הקוד הבא מספק דוגמה להמחשה של ה-API:

   SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
       OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
   

2. ערכת ה-SDK מקבלת הודעה שהיא נטענה ומחזירה את הממשק שלה. הממשק הזה מיועד לשימוש בתהליך של האפליקציה. כדי לשתף את הממשק מחוץ לגבולות התהליך, צריך להחזיר אותו כאובייקט IBinder.

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

3. ‫SdkSandboxManager מקבל את הממשק של IBinder ומחזיר אותו לאפליקציה.

4. האפליקציה מקבלת את IBinder ומבצעת המרה שלו לממשק SDK, וקוראת לפונקציות שלו:

   IBinder binder = sandboxSdk.getInterface();
   ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
   mySdkInterface.something();
   

האפליקציה יכולה גם להציג מדיה מה-SDK. כך עושים זאת:

1. כפי שמוסבר בקטע על עיבוד מדיה במסמך הזה, כדי שאפליקציה תקבל SDK לעיבוד מדיה בתצוגה, האפליקציה יכולה לבצע קריאה ל-requestSurfacePackage() ולאחזר את SurfaceControlViewHost.SurfacePackage המתאים.

   קטע הקוד הבא מספק דוגמה להמחשה של ה-API:

   SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
           Executor executor,
           OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
   

2. לאחר מכן האפליקציה יכולה להטמיע את הערך SurfacePackage שהוחזר ב-SurfaceView באמצעות setChildSurfacePackage API ב-SurfaceView.

   קטע הקוד הבא מספק דוגמה להמחשה של ה-API:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

ההצעה שלנו היא שממשקי ה-API‏ IBinder ו-requestSurfacePackage() יהיו כלליים ולא מיועדים לקריאה ישירה על ידי האפליקציות. במקום זאת, קריאה לממשקי ה-API האלה תתבצע על ידי הפניית ה-API שנוצרה, שצוינה למעלה, בשכבת shim, כדי להקל על מפתחי האפליקציות.

SDK-to-SDK

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

יש שני תרחישים עיקריים שכדאי לקחת בחשבון:

• כששתי ערכות ה-SDK תואמות זמן ריצה. במקרה הזה, שתי ערכות ה-SDK פועלות בזמן הריצה ל-SDK עם כל אמצעי ההגנה שלו. ערכות ה-SDK לא יכולות לתקשר כמו שהן מתקשרות היום בתוך אפליקציה. לכן, נוסף API ב-SdkSandboxController כדי לאפשר אחזור של אובייקטים מסוג SandboxedSdk לכל ערכות ה-SDK של RE שנטענו. הפעולה הזו מאפשרת ל-RE-SDK לתקשר עם ערכות SDK אחרות שנטענו ב-SDK Runtime.
• כשיש רק ערכת SDK אחת שמופעלת בזמן ריצה.
  • אם ה-SDK שקורא לפונקציה פועל באפליקציה, הפעולה לא שונה מהמצב שבו האפליקציה עצמה קוראת לפונקציה ב-SDK השני בזמן הריצה ל-SDK.
  • אם ה-SDK ששולח את הקריאה פועל בזמן הריצה של ה-SDK, בהצעה הזו מומלץ לחשוף method באמצעות IBinder שמתואר בקטע בנושא תקשורת בין אפליקציה ל-SDK. הקוד באפליקציה מאזין ל-method, מעבד אותה ומגיב באמצעות הקריאות החוזרות שסופקו.
  • יכול להיות שערכות SDK להצגת מודעות שלא מופעלות בזמן ריצה לא יוכלו להירשם בעצמן. אנחנו מציעים ליצור SDK לגישור שיכלול את כל ערכות ה-SDK של השותפים או האפליקציות כתלות ישירה של האפליקציה, ויטפל ברישום. ה-SDK הזה של פלטפורמת הגישור יוצר תקשורת בין ערכות SDK שלא תואמות לזמן ריצה או בין תלויות אחרות באפליקציה לבין פלטפורמת הגישור שתואמת לזמן ריצה ופועלת כמתאם.

התכונות של תקשורת בין ערכות SDK חולקו לקטגוריות הבאות:

• תקשורת בין SDK ל-SDK בזמן הריצה ל-SDK (זמין בתצוגה המקדימה האחרונה למפתחים)
• תקשורת בין SDK ל-SDK בין אפליקציה לבין זמן הריצה ל-SDK (זמין בתצוגה המקדימה האחרונה למפתחים)
• איך צפיות ועיבוד מרחוק אמורים לפעול בתהליך בחירת הרשת (הצעה בפיתוח)

במהלך התכנון של הפרימיטיבים, אנחנו בוחנים את תרחישי השימוש הבאים:

1. תהליך בחירת הרשת (Mediation) ובידינג. הרבה ערכות SDK לפרסום מציעות יכולת בחירת רשת או בידינג, שבהן ערכת ה-SDK קוראת לערכות SDK אחרות כדי להציג חשיפה של מודעה (בחירת רשת) או כדי לאסוף אותות להפעלת מכרז (בידינג). בדרך כלל, ערכת ה-SDK המתאמת קוראת לערכות SDK אחרות דרך מתאם שמסופק על ידי ערכת ה-SDK המתאמת. בהינתן הפרימיטיבים שלמעלה, ערכת ה-SDK לתיאום, בין אם היא RE או לא, אמורה להיות מסוגלת לגשת לכל ערכות ה-SDK מסוג RE ומסוג שאינו RE לצורך פעולה רגילה. הרינדור בהקשר הזה הוא תחום מחקר פעיל.
2. גילוי תכונות. חלק ממוצרי ה-SDK מורכבים מערכות SDK קטנות יותר, שבאמצעות תהליך של גילוי בין מערכות SDK, קובעות את קבוצת התכונות הסופית שמוצגת למפתח האפליקציה. אמצעי פרימיטיביים לרישום ולגילוי צפויים לאפשר את תרחיש השימוש הזה.
3. מודלים של מינויים למוציאים לאור. חלק מערכות ה-SDK מתוכננות כך שיהיה להן מפרסם מרכזי של אירועים, שאפליקציות או ערכות SDK אחרות יכולות להירשם אליו כדי לקבל התראות באמצעות קריאות חוזרות (callback). הפרימיטיבים שלמעלה אמורים לתמוך בתרחיש השימוש הזה.

אפליקציה לאפליקציה

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

• ה-SDK לא יכול להגדיר רכיבים כמו <service>, <contentprovider> או <activity> במניפסט שלו.
• ה-SDK לא יכול לפרסם ContentProvider או לשלוח שידור.
• ה-SDK יכול להפעיל פעילות ששייכת לאפליקציה אחרת, אבל יש מגבלות על מה שאפשר לשלוח ב-Intent. לדוגמה, אי אפשר להוסיף ל-Intent הזה תוספים או פעולות מותאמות אישית.
• ה-SDK יכול להתחיל או להתחבר רק לרשימת היתרים של שירותים.
• ה-SDK יכול לגשת רק לחלק ממערכת ContentProvider (למשל com.android.providers.settings.SettingsProvider), שבה הנתונים שמתקבלים לא כוללים מזהים ולא ניתן להשתמש בהם כדי ליצור טביעת אצבע של המשתמש. הבדיקות האלה חלות גם על גישה אל ContentProvider באמצעות ContentResolver.
• ערכת ה-SDK יכולה לגשת רק לקבוצת משנה של מקלטי שידור מוגנים (כמו android.intent.action.AIRPLANE_MODE).

תגי מניפסט

כשמנסים להתקין את ה-SDK,‏ PackageManager מנתח את המניפסט של ה-SDK, ואם יש בו תגי מניפסט אסורים, ההתקנה נכשלת. לדוגמה, יכול להיות שה-SDK לא יגדיר רכיבים כמו <service>, <activity>, <provider> או <receiver>, ולא יצהיר על <permission> במניפסט. תגים שלא מצליחים להתקין לא נתמכים ב-SDK Runtime. יכול להיות שגרסאות עתידיות של Android יתמכו בתגים שלא גורמים לכשל בהתקנה אבל מתעלמים מהם בשקט.

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

תמיכה בפעילות

ערכות SDK בסביבת זמן הריצה ל-SDK לא יכולות להוסיף תג פעילות לקובץ המניפסט שלהן ולא יכולות להתחיל פעילויות משלהן באמצעות Context.startActivity. במקום זאת, הפלטפורמה יוצרת את הפעילויות עבור ערכות ה-SDK כשמתקבלת בקשה, ומשתפת אותן עם ערכות ה-SDK.

פעילות הפלטפורמה היא מסוג android.app.Activity. פעילות הפלטפורמה מתחילה מאחת הפעילויות של האפליקציה והיא חלק ממשימת האפליקציה. אין תמיכה ב-FLAG_ACTIVITY_NEW_TASK.

כדי ש-SDK יתחיל פעילות, הוא צריך לרשום מופע מסוג SdkSandboxActivityHandler שמשמש להודעה על יצירת פעילות כשהאפליקציה קוראת ל-SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) כדי להתחיל את הפעילות.

בתרשים הבא מוצג תהליך הבקשה של פעילות.

פיתוח

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

יצירת תוכן

‫Android Studio וכלי פיתוח קשורים יעודכנו כך שיתאימו לזמן הריצה ל-SDK, כדי לעזור למפתחים לוודא שהם הגדירו נכון את האפליקציות ואת ערכות ה-SDK שלהם, וכדי לוודא שקריאות (calls) מדור קודם או קריאות לא נתמכות יעודכנו לחלופות חדשות יותר, איפה שרלוונטי. במהלך שלב הכתיבה, יש כמה שלבים שההצעה שלנו מחייבת את המפתחים לבצע.

מפתחי אפליקציות

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

• שם: שם החבילה של ה-SDK או הספרייה.
• גרסה ראשית: קוד הגרסה הראשית של ה-SDK.
• תקציר (digest) של האישור: תקציר האישור של גרסת ה-SDK. לגבי כל גרסת build, אנחנו מציעים שמפתח ה-SDK יקבל וירשום את הערך הזה דרך חנות האפליקציות הרלוונטית.

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

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

מפתחי SDK

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

• שם: שם החבילה של ה-SDK או הספרייה.
• גרסה ראשית: קוד הגרסה הראשית של ה-SDK.
• גרסה משנית: קוד הגרסה המשנית של ה-SDK.

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

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

גרסאות Build

מפתחי אפליקציות

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

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

אנחנו נמצאים בשלב מוקדם יותר של תכנון, ונעדכן אתכם כשהתכנון יתקדם.

מפתחי SDK

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

בדומה לאפליקציות, ערכות SDK של תלות שמופצות בחנות אפליקציות צריכות להיות במחשב כדי לבצע בדיקת lint, קומפילציה ובנייה, ואנחנו מצפים ש-Android Studio יאפשר זאת בצורה חלקה.

בדיקה

מפתחי אפליקציות

כפי שמתואר בהצעה שלנו, מפתחי אפליקציות יוכלו לבדוק את האפליקציות שלהם במכשירים עם Android 14 כמו שהם בדרך כלל עושים. אחרי שהם יבנו את האפליקציה, הם יוכלו להתקין אותה במכשיר RE או באמולטור. תהליך ההתקנה הזה יבטיח שערכות ה-SDK הנכונות יותקנו ב-SDK Runtime במכשיר או באמולטור, בין אם ערכות ה-SDK נמשכו ממאגר SDK מרוחק או ממטמון ממערכת ה-Build.

מפתחי SDK

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

הפצה

ההפרדה בין אפליקציה לבין ערכות ה-SDK שלה יצרה אפשרות להפצת ערכות SDK בחנות האפליקציות. זוהי תכונה של הפלטפורמה, שלא ספציפית לאף ערוץ הפצה.

היתרונות בהסקת פרטי משלוח:

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

כדי לתמוך בהפצת SDK, ערוץ הפצה צריך לתמוך ביכולות הבאות:

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

הגבלות משתנות לאורך זמן

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

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

שאלות נפוצות

1. מה זה SDK שקשור לפרסום?

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

2. האם אפשר להריץ כל SDK בזמן הריצה ל-SDK?

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

3. למה כדאי לבחור בבידוד תהליכים במקום בבידוד בסביבת ריצה מבוססת Java של תהליך?

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

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

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

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

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

מומלץ בשבילכם

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