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

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

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

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

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

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

יעדים

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

גישה

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

הרשאות SDK

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

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

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

זיכרון

לזמן הריצה ל-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 בחלופה כמו הגרסה המובנית של SQLite ב-Android SDK.

SELinux

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

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

ממשקי API

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

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

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

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

מחזור חיים

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

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

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

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

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

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

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

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

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

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

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

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

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

רינדור מדיה

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

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

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

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

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

תקשורת

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

אפליקציה ל-SDK

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

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

SDK-to-SDK

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

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

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

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

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

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

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

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

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

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

תגי מניפסט

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

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

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

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

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

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

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

פיתוח

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

יצירת תוכן

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

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

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

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

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

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

מפתחי SDK

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

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

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

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

גרסאות Build

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

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

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

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

מפתחי SDK

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

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

בדיקה

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

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

מפתחי SDK

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

הפצה

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

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

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

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

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

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

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

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

שאלות נפוצות

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

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

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

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

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

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

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

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

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

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

מומלץ עבורך

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