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

שליחת משוב

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

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

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

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

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

שערים

הצעה זו נועדה להשיג את היעדים הבאים:

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

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

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

---

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

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

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

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

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

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

---

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

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

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

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

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

גישה

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

הרשאות SDK

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

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

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

זיכרון

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

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

ממשקי API

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

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

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

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

מחזור חיים

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

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

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

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

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

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

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

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

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

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

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

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

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

עיבוד מדיה

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

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

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

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

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

תקשורת

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

App-to-SDK (אפליקציה ל-SDK)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

האפליקציה יכולה גם לעבד מדיה מה-SDK על ידי ביצוע השלבים הבאים:

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

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

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

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

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

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

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

SDK ל-SDK

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

יש שני מקרים עיקריים שצריך לשקול:

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

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

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

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

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

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

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

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

תגי מניפסט

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

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

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

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

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

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

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

פיתוח

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

כתיבה

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

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

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

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

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

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

מפתחי SDK

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

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

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

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

גרסאות build

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

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

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

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

מפתחי SDK

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

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

בדיקה

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

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

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

שאלות נפוצות

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

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

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

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

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

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

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

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

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

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

מומלץ עבורכם

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