בפלטפורמת 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 לבין הפצת האפליקציה. ההצעה שלנו כוללת מנגנון התקנה והפצה מהימן, כדי להבטיח ש-SDKs נכונים מותקנים בסביבת זמן הריצה של ה-SDK באפליקציה. כך אפשר להגן על המשתמשים ועל מפתחי האפליקציות מפני טעינת ערכות SDK לא חוקיות, ובמקביל לאפשר לחנויות האפליקציות לצמצם באופן משמעותי את העומס על מפתחי האפליקציות בנוגע להפצת ערכות SDK.
לא תצטרכו יותר לקשר ערכות SDK באופן סטטי ולארז אותן יחד עם האפליקציות שלכם לפני ההעלאה לחנות האפליקציות לצורך הפצה. במקום זאת, התהליך הבא יתבצע:
- מפתחי SDK יוכלו להעלות את ערכות ה-SDK עם הגרסאות שלהם לחנויות האפליקציות, בנפרד מהאפליקציות עצמן.
- מפתחי אפליקציות יכולים לציין את יחסי התלות שלהם ב-SDK לפי גרסה, ליצור גרסה של האפליקציה ולהעלות אותה בלי לכלול את יחסי התלות בפועל ב-SDK.
- כשמשתמש מוריד את האפליקציה הזו, תהליך ההתקנה יכול להשתמש ביחסי התלות של ה-SDK שצוינו באפליקציה כדי להוריד אותם מחנות האפליקציות.
מנגנון ההפצה החדשני הזה יאפשר למפתחי SDK לבצע שינויים ב-SDK שלהם שלא משבשים את הפעולה (כלומר, ללא שינויים בממשקי ה-API או בסמינטיקה שלהם) ולפזר אותם למכשירים בלי מעורבות של מפתחי האפליקציות. אפשר לפרוס או לבטל את השינויים האלה ב-SDK בלי לחכות למפתחי האפליקציות שיבנו מחדש את האפליקציות שלהם עם ערכות ה-SDK החדשות, או לחכות למשתמשים הקצה שיעדכנו את האפליקציות שלהם. מפתחי האפליקציות עדיין יצטרכו לעדכן שינויים משמעותיים, אבל מפתחי ה-SDK יוכלו להפיץ את התיקונים והשינויים האחרונים שאינם משמעותיים מהר יותר ובאופן אחיד יותר ליותר אנשים, ובאופן אידיאלי לצמצם את התמיכה בגרסאות.
בתרשים הבא מוצגים השינויים המוצעים בהפצת ה-SDK:
שינויים באופן יצירת ערכות SDK ואפליקציות, הפעלתן והפצתן
זוהי הצעה ראשונית לטכנולוגיית הפצה וזמן ריצה גמישים של SDK. בקטעים הבאים מוצגות הצעות לשינויים בקטגוריות הרחבות הבאות:
- גישה: הרשאות, זיכרון, אחסון
- ביצוע: שפות, שינויים בסביבת זמן הריצה, מחזור חיים, עיבוד מדיה
- תקשורת: בין האפליקציה ל-SDK ובין SDK ל-SDK
- פיתוח: איך יוצרים, מנפים באגים ובודקים את המודל הזה
- הפצה: איך להפיץ, לעדכן ולבצע חזרה לגרסה הקודמת בגרסאות של Android, אפליקציות ו-SDKs
המסמך הזה כולל גם שאלות נפוצות שיעזרו לכם לענות על שאלות נפוצות.
זוהי הצעה ראשונית לעיצוב, ואנחנו מבינים שיכול להיות שמדובר בשינוי משמעותי לחלק מהגורמים בסביבה העסקית. לכן אנחנו מבקשים ממך לשלוח לנו משוב דרך כלי המעקב אחרי בעיות.
גישה
ניהול הפרטיות של מערכת כולל ניהול האופן שבו גורמים שונים יכולים לגשת למשאבים שונים. כדי לעמוד בחזון שלנו בנושא פרטיות, אנחנו מציעים לעדכן את המודל לגישה לאפליקציות, ל-SDK ולנתוני משתמשים בהתאם לעיקרון של הרשאות מינימליות, כדי למנוע גישה לא ידועה למידע שעשוי להיות רגיש.
הרשאות SDK
בתור תהליך נפרד, ל-SDK Runtime תהיה קבוצה מוגדרת היטב משלו של הרשאות, במקום לרשת את ההרשאות שהמשתמש העניק לאפליקציה. על סמך מחקר ראשוני על ההרשאות שבהן נעשה שימוש ב-SDK שקשור למודעות, אנחנו מציעים שההרשאות הבאות יהיו נגישות ל-SDK ב-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. בתרשים הבא מוצגת גישה שאנחנו שוקלים:
הפלטפורמה תציג ממשקי API חדשים לאפליקציות, שיאפשרו להן לטעון ערכות SDK באופן דינמי לתהליך של SDK Runtime, לקבל התראות על שינויים במצב התהליך ולנהל אינטראקציה עם ערכות SDK שנטענו ל-SDK Runtime.
בתרשים הקודם מוצגת תקשורת בין האפליקציה ל-SDK ברמה נמוכה יותר, ללא שכבת ה-marshaling.
האפליקציה מתקשרת עם ה-SDK שפועל בתהליך של זמן הריצה של ה-SDK באמצעות השלבים הבאים:
כדי שאפליקציה תוכל לקיים אינטראקציה עם SDK, היא צריכה לבקש מהפלטפורמה לטעון את ה-SDK. כדי להבטיח את תקינות המערכת, האפליקציות יצטרכו לציין בקובץ המניפסט את ערכות ה-SDK שהן מתכוונות לטעון, ורק ערכות ה-SDK האלה יהיו מורשות לטעינה.
קטע הקוד הבא הוא דוגמה להפעלת API:
SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor, OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)ערכת ה-SDK מקבלת הודעה על כך שהיא נטענה ומחזירה את הממשק שלה. הממשק הזה מיועד לשימוש בתהליך האפליקציה. כדי לשתף את הממשק מחוץ לגבולות התהליך, צריך להחזיר אותו כאובייקט
IBinder.במדריך לשירותים מקושרים מפורטות דרכים שונות לספק את
IBinder. לא משנה באיזו דרך תבחרו, היא חייבת להיות עקבית בין ה-SDK לאפליקציה הקוראת. בתרשים מוצגת דוגמה ל-AIDL.ה-
SdkSandboxManagerמקבל את הממשקIBinderומחזיר אותו לאפליקציה.האפליקציה מקבלת את
IBinderומבצעת עליו הטמעה (cast) לממשק ה-SDK, ומפעילה את הפונקציות שלו:IBinder binder = sandboxSdk.getInterface(); ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder); mySdkInterface.something();
האפליקציה יכולה גם ליצור עיבוד (רנדור) של מדיה מה-SDK באופן הבא:
כפי שמוסבר בקטע 'עיבוד מדיה' במסמך הזה, כדי שאפליקציה תוכל לקבל SDK לעיבוד מדיה בתצוגה, היא יכולה לבצע קריאה ל-
requestSurfacePackage()ולאחזר אתSurfaceControlViewHost.SurfacePackageהמתאים.קטע הקוד הבא הוא דוגמה להפעלת API:
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams, Executor executor, OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)לאחר מכן, האפליקציה יכולה להטמיע את הערך
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 האחרונה)
- איך הצגות ורינדור מרחוק אמורים לפעול לצורך בחירת רשת (הצעה בפיתוח)
התרחישים הבאים לדוגמה נלקחים בחשבון במהלך תכנון הפרימיטיבים:
- תהליך בחירת הרשת (Mediation) ובידינג. ערכות SDK רבות לפרסום מציעות יכולת של תהליך בחירת רשת או בידינג, שבה ערכת ה-SDK קוראת לערכות SDK אחרות לצורך חשיפת מודעה (תהליך בחירת רשת) או לצורך איסוף אותות להפעלת מכרז (בידינג). בדרך כלל, ערכת ה-SDK שתואמת את הרכיבים מפעילה ערכות SDK אחרות דרך מתאם שסופק על ידי ערכת ה-SDK שתואמת את הרכיבים. בהתאם לרכיבים הבסיסיים שלמעלה, ערכת ה-SDK שתואמת ל-RE או לא, אמורה להיות מסוגלת לגשת לכל ערכות ה-SDK של RE ושל מודעות ללא RE לצורך פעולה רגילה. עיבוד בקונטקסט הזה הוא תחום מחקר פעיל.
- גילוי תכונות. חלק ממוצרים של SDK מורכבים מ-SDKs קטנים יותר, שמגדירים את קבוצת התכונות הסופית שחשופה למפתח האפליקציה באמצעות תהליך של זיהוי בין SDKs. רכיבי היסוד של הרישום והגילוי צפויים לאפשר את תרחיש לדוגמה הזה.
- מודלים של מינויים לבעלי תוכן דיגיטלי. חלק מערכות ה-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 ישתנו בגרסאות מתקדמות יותר של Android. כדי להבטיח תאימות של האפליקציות, לא נשנה את ההגבלות האלה עם עדכוני המודולים הראשיים ברמת SDK מסוימת. ההתנהגות שמשויכת ל-targetSdkVersion מסוים נשמרת עד שהתמיכה ב-targetSdkVersion הזה תופסק בהתאם למדיניות של חנות האפליקציות, וייתכן שההוצאה משימוש של targetSdkVersion תתבצע בקצב מהיר יותר מאשר של אפליקציות.
צפויות שינויים תכופים בהגבלות בגרסאות השונות של Android SDK, במיוחד בגרסאות הראשונות.
בנוסף, אנחנו מפתחים מנגנון 'כנרית' שיאפשר למבדקים חיצוניים ופנימיים להצטרף לקבוצה שתקבל את קבוצת ההגבלות המוצעת לגרסה הבאה של Android. כך נוכל לקבל משוב ולקבל ביטחון לגבי השינויים המוצעים בקבוצת ההגבלות.
שאלות נפוצות
-
מהו SDK שקשור לפרסום?
ערכת SDK שקשורה למודעות היא ערכה שמאפשרת לבצע כל חלק בתהליך הטירגוט של משתמשים להצגת הודעות למטרות מסחריות, באפליקציות שלא בבעלות המפרסם. הרשאות האלה כוללות, בין היתר, ערכות SDK לניתוח נתונים שבהן אפשר ליצור קבוצות משתמשים לטירגוט עתידי, ערכות SDK להצגת מודעות, ערכות SDK למניעת התנהלות פוגעת ומניעת הונאות במודעות, ערכות SDK ליצירת אינטראקציה וערכות SDK לשיוך (Attribution).
-
האם כל ערכת SDK יכולה לפעול בסביבת זמן הריצה ל-SDK?
ההתמקדות הראשונית היא בערכות SDK שקשורות למודעות, אבל מפתחים של ערכות SDK שלא קשורות למודעות, שרוצים לתמוך בפרטיות וסבורים שהם יכולים לפעול בהתאם לתנאים שמפורטים למעלה, יכולים לשתף משוב על ערכות ה-SDK שלהם שפועלות בסביבת זמן הריצה ל-SDK. עם זאת, זמן הריצה ל-SDK לא תוכנן להיות תואם לכל העיצובים של SDK. בנוסף למגבלות המתועדות, סביר להניח שזמן הריצה ל-SDK לא מתאים ל-SDKs שצריכים תקשורת בזמן אמת או תקשורת עם תפוקה גבוהה עם אפליקציית האירוח.
-
למה כדאי לבחור בביצוע בידוד של תהליכים במקום בידוד בזמן הריצה של Java בתהליך?
בשלב זה, סביבת זמן הריצה שמבוססת על Java לא מאפשרת בקלות להגדיר את גבולות האבטחה הנדרשים כדי להבטיח את הפרטיות של משתמשי Android. סביר להניח שההטמעה של משהו כזה תדרוש מאמץ של כמה שנים, ללא ערובה להצלחה. לכן, ארגז החול לפרטיות משתמש בגבולות של תהליך השימוש, טכנולוגיה מוכחת ומובנת.
-
האם העברת ערכות ה-SDK לתהליך זמן הריצה של ה-SDK תאפשר לחסוך בגודל ההורדה או במרחב האחסון?
אם כמה אפליקציות משולבות עם ערכות SDK שפועלות בזמן ריצה מאותה גרסת, אפשר לצמצם את גודל ההורדה ואת נפח האחסון בדיסק.
-
לאילו אירועים במחזור החיים של האפליקציה, כמו מעבר של האפליקציה לרקע, תהיה ל-SDK גישה במהלך זמן הריצה של ה-SDK?
אנחנו עובדים בשיא המרץ על תמיכה בתכנון של התראות בסביבת זמן הריצה של ה-SDK לגבי אירועים במחזור החיים של אפליקציית הלקוח ברמת האפליקציה (למשל, האפליקציה עוברת לרקע, האפליקציה עוברת לחזית). העיצוב והקוד לדוגמה ישותפו בתצוגה מקדימה למפתחים שתתקיים בקרוב.
מומלץ עבורך
- הערה: טקסט הקישור מוצג כש-JavaScript מושבת
- מדריך למפתחים בנושא SDK Runtime