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

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

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

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

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

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

יעדים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

גישה

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

הרשאות SDK

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

  • 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 ב-Android SDK.

SELinux

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

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

ממשקי API

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

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

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

לבסוף, ערכות SDK של RE לא יכולות להשתמש ב-API של ההתראות כדי לשלוח התראות למשתמשים בכל שלב.

מחזור חיים

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

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

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

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

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

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

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

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

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

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

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

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

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

רינדור מדיה

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

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

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

בריאות המערכת

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

תקשורת

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

אפליקציה ל-SDK

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

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

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

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

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

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

דיאגרמה
תרשים רצף שבו מוצגות האינטראקציות בין האפליקציה ל-SDK במהלך ההפעלה של האפליקציה ושל ה-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 לאפליקציה הקוראת. בתרשים מוצגת דוגמה ל-AIDL.

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

  4. האפליקציה מקבלת את IBinder ומבצעת עליו הטמעה (cast) לממשק ה-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 באמצעות ה-API של setChildSurfacePackage ב-SurfaceView.

    קטע הקוד הבא הוא דוגמה להפעלת API:

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)

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

SDK ל-SDK

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

יש שני מקרים מרכזיים שכדאי לשקול:

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

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

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

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

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

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

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

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

תגי מניפסט

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

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

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

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

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

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

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

דיאגרמה
תרשים רצף שמראה את התהליך של התחלת פעילות.

פיתוח

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

כתיבת תוכן

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

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

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

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

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

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

מפתחי SDK

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

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

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

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

גרסאות build

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

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

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

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

מפתחי SDK

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

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

בדיקה

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

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

מפתחי SDK

בדרך כלל, מפתחי SDK משתמשים באפליקציות בדיקה פנימיות במכשירים ובמכונות וירטואליות כדי לבדוק את הפיתוח שלהם. ההצעה שלנו לא משנה את המצב הזה, והאימות באפליקציה יתבצע לפי אותם שלבים שמפורטים למפתחי האפליקציות למעלה, עם ארטיפקט build אחד גם לאפליקציות ל-RE וגם לאפליקציות ללא RE. מפתחי SDK יוכלו לעבור על הקוד שלהם, גם אם הוא לא נמצא בסביבת זמן הריצה של ה-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 לשיוך (Attribution).

  2. האם כל ערכת SDK יכולה לפעול בסביבת זמן הריצה ל-SDK?

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

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

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

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

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

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

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