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

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

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

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

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

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

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

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

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

מפתחי SDK

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

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