בפלטפורמת Android נעשה שימוש בתפיסה של הרצה בארגז חול של אפליקציות כדי לשמור על גבולות אבטחה וביצועים חזקים לקוד האפליקציה, לצד גבולות התהליך. אפליקציות נוהגות לכלול קוד של צד שלישי לעיתים קרובות בפורמט של ערכות SDK, כמו ערכות SDK להצגת מודעות או ערכות SDK לניתוח נתונים. השימוש החוזר הזה מפעיל את האפליקציה למפתחים להתמקד בייחד את האפליקציה שלהם תוך מינוף העבודה כדי להגדיל את היקף הביצוע שלהם מעבר למה שהם יכולים לעשות בקלות בפני עצמם.
בדומה לרוב מערכות ההפעלה, ב-Android SDKs פועלים בתוך ארגז החול של האפליקציה המארחת, ויורשים את אותן ההרשאות והזכויות של האפליקציה המארחת, וגם גישה לזיכרון ולאחסון של האפליקציה המארחת. הארכיטקטורה הזו מאפשרת לשלב ערכות 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 והפצת אפליקציות. ההצעה שלנו כוללת מנגנון התקנה והפצה מהימן, כדי להבטיח ש-SDKs נכונים מותקנים בסביבת זמן הריצה של ה-SDK באפליקציה. כך אפשר להגן על המשתמשים ועל מפתחי האפליקציות מפני טעינת ערכות SDK לא חוקיות, ולאפשר לחנויות האפליקציות לצמצם באופן משמעותי את העומס על מפתחי האפליקציות בנוגע להפצת ערכות SDK.
לא יהיה יותר צורך לקשר באופן סטטי לערכות SDK ולארוז אותן יחד עם לפני שהם מעלים את האפליקציות לחנות אפליקציות להפצה. הבאים במקום זאת:
- מפתחי SDK יכולים להעלות את גרסאות ה-SDK שלהם לחנויות האפליקציות, בנפרד מהאפליקציות עצמן.
- מפתחי אפליקציות יכולים לציין את יחסי התלות של ה-SDK שלהם גרסה, build והעלאה של גרסת אפליקציה שלא כוללת את ה-SDK בפועל של יחסי התלות.
- כשמשתמש יוריד את האפליקציה הזו, תהליך ההתקנה עשוי להשתמש את יחסי התלות שצוינו ב-SDK של האפליקציה כדי להוריד אותם מחנות האפליקציות.
מנגנון ההפצה החדשני הזה יאפשר למפתחי SDK לבצע שינויים ב-SDK שלהם שלא משבשים את הפעולה (כלומר, ללא שינויים בממשקי ה-API או בסמינטיקה שלהם) ולפזר אותם למכשירים בלי מעורבות של מפתחי האפליקציות. ניתן לפרוס את השינויים הלא-תקינים האלה ב-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 יהיה מרחב זיכרון מבודד הודות לתהליך משלו. המבנה הזה כברירת מחדל ידחה את גישת SDK לשטח הזיכרון של האפליקציה, ובאופן דומה האפליקציה לא תהיה אפשרות לגשת לשטח הזיכרון של ה-SDK. אנחנו מציעים להשאיר את ברירת המחדל הזאת כדי לשמור על עקרון של הרשאות מינימליות.
אחסון
ההצעה הזו נועדה לאזן בין הצורך בערכות SDK לגישה לאחסון פעילות רגילה ולצמצם את המעקב בין אפליקציות שונות ותהליכים שונים באמצעות אחסון מתמיד. אנחנו מציעים את העדכון הבא לגישה לאחסון כיום:
- לאפליקציה לא תהיה גישה ישירה לאחסון ערכות ה-SDK שלה, ולהפך.
- לא תהיה גישה של ערכות SDK לאחסון החיצוני של המכשיר.
- בכל זמן ריצה ל-SDK, יהיה אחסון שכל ערכות ה-SDK יכולות לגשת אליו, ואחסון פרטי לערכת SDK מסוימת.
כמו למודל האחסון הנוכחי, לאחסון עצמו לא יהיו מגבלות שרירותיות בגודל. ערכות SDK יכולות להשתמש באחסון כדי לשמור נכסים במטמון. האחסון הזה תקופתי נמחקת כשערכת ה-SDK לא פועלת.
ביצוע
כדי להבטיח מערכת פרטית בין אפליקציות, ערכות SDK ומשתמשים, הקשר של הביצוע עצמו (פורמטים של קוד, מבני שפה, ממשקי API נגישים ונתוני מערכת) צריך לחזק את גבולות הפרטיות האלה, או לפחות לא לספק הזדמנויות לעקוף אותם. עם זאת, אנחנו רוצים לשמור על הגישה לפלטפורמה העשירה ועל רוב היכולות של זמן הריצה שקיימות כרגע ב-SDK. כאן אנחנו מציעים סדרה של עדכונים לסביבת זמן הריצה להגיע לאיזון הזה.
קוד
קוד Android (אפליקציות וערכות SDK) מפרש בעיקר על ידי זמן הריצה של Android (ART), האם הקוד נכתב ב-Kotlin או ב-Java. העושר של ART ומבנוי השפה שהיא מציעה, יחד עם יכולת האימות שהיא מציעה. כשמשווים אותו לחלופות - ובמיוחד קוד נייטיב - נראה מתאים לאזן בין פונקציונליות לבין פרטיות. אנחנו מציעים שקוד SDK שתואם לזמן ריצה כוללים רק בייטקוד Dex, ולא תומכים בגישת JNI.
אנחנו מודעים לכך שיש תרחישים לדוגמה, כמו שימוש ב-SQLite בחבילה בהתאמה אישית, שבהם, בגלל השימוש בקוד מקורי, צריך להחליף את הקוד בגרסה מובנית של SQLite ב-Android SDK.
SELinux
ב-Android, כל תהליך (כולל תהליכים שפועלים ברמה הבסיסית) פועל עם הקשר של SELinux, שמאפשר לליבה לנהל את בקרת הגישה למערכת שירותים, קבצים, מכשירים ותהליכים אחרים. כדי לשמור על רוב התרחישים לדוגמה של שימוש ב-SDK, תוך צמצום האפשרות לעקוף את אמצעי ההגנה על הפרטיות שאנחנו מנסים לקדם, אנחנו מציעים את העדכונים הבאים מההקשר של SELinux באפליקציה שאינה מערכת, עבור זמן הריצה של ה-SDK:
- תהיה גישה לקבוצה מוגבלת של שירותי מערכת. (בשלבי עיצוב פעיל)
- ערכות SDK יוכלו לטעון ולהפעיל את הקוד רק ב-APK.
- תהיה גישה לקבוצה מוגבלת של מאפייני מערכת. (בעיצוב פעיל)
ממשקי API
מותר להשתמש בממשקי API של השתקפות והפעלה בתוך זמן הריצה של ה-SDK. עם זאת, אסור ל-SDK להשתמש בהשתקפות או להפעיל ממשקי API ב-SDK אחר שפועל בסביבת זמן ריצה. נשתף הצעה מלאה של ממשקי API אסורים בעדכון עתידי.
בנוסף, הגרסאות האחרונות של פלטפורמת Android מוגבלות יותר ויותר גישה למזהים קבועים כדי לשפר את הפרטיות. ל-SDK אנחנו מציעים להגביל עוד יותר את הגישה למזהים שאפשר להשתמש בהם למעקב בין אפליקציות.
אפשר לגשת לממשקי ה-API של זמן הריצה ל-SDK רק מאפליקציות שפועלות בחזית.
ניסיון לגשת לממשקי API של SdkSandboxManager מאפליקציות ברקע גורם להשלכת SecurityException.
לסיום, ערכות SDK מחדש לא יכולות להשתמש בממשקי ה-API של התראות כדי לשלוח התראות למשתמשים בכל נקודה בזמן.
מחזור חיים
נכון לעכשיו, ערכות SDK של אפליקציות פועלות לפי מחזור החיים של האפליקציה המארחת שלהן. כלומר, כשהאפליקציה נכנס לחזית או יוצא ממנה, נכבה או מונע בכוח על ידי במערכת ההפעלה עקב לחץ על הזיכרון, גם ערכות ה-SDK של האפליקציה משתמשות בו. ההצעה שלנו להפריד את רכיבי ה-SDK של אפליקציה לתהליך אחר מובילה לשינויים הבאים במחזור החיים:
- המשתמש או מערכת ההפעלה יכולים לסיים את האפליקציה. סביבת זמן הריצה של ה-SDK תסתיים באופן אוטומטי מיד לאחר מכן.
מערכת ההפעלה יכולה לסיים את זמן הריצה של ה-SDK בגלל זיכרון לחץ, או חריג לא מטופל ב-SDK, לדוגמה.
ב-Android 13, כשאפליקציה נמצאת בחזית, זמן הריצה ל-SDK פועל בעדיפות גבוהה וסביר להניח שהוא לא יופסק. כשהאפליקציה עוברת לרקע, העדיפות של תהליך SDK Runtime יורדת והוא הופך מתאים לסגירה. העדיפות של תהליך SDK Runtime נשארת נמוכה גם אם האפליקציה חוזרת לחזית. לכן חשוב מאוד שהוא יסתיים עקב לחץ על הזיכרון בהשוואה אפליקציה.
ב-Android מגרסה 14 ואילך, סדר העדיפויות של התהליכים של האפליקציה וה-SDK זמני הריצה תואמים. עדיפויות של תהליכים עבור
ActivityManager.RunningAppProcessInfo.importanceלאפליקציה וגם זמן הריצה של ה-SDK אמור להיות די דומה.במקרה שזמן הריצה של ה-SDK מסתיים כשהאפליקציה פעילה – לדוגמה, אם יש חריג שלא מטופל ב-SDK – זמן הריצה של ה-SDK המצב, כולל כל ערכות ה-SDK והתצוגות המרוחקות שנטענו בעבר, יאבד. מפַתח אפליקציות יכול לטפל בסיום זמן הריצה של ה-SDK באמצעות כל אחד השיטות הבאות:
- ההצעה כוללת שיטות קריאה חוזרת (callbacks) שקשורות למחזור החיים של מפתחי האפליקציות, כדי לזהות מתי זמן הריצה של ה-SDK הסתיים.
- אם זמן הריצה של ה-SDK מסתיים במהלך הצגת המודעות, ייתכן שהמודעות לא פועלות כמצופה. לדוגמה, יכול להיות שהתצוגה תוקפא במסך ולא תהיה אינטראקטיבית יותר. האפליקציה יכולה להסיר את תצוגת המודעה אם היא לא משפיעה על חוויית המשתמש.
- האפליקציה יכולה לנסות שוב לטעון ערכות SDK ולבקש מודעות.
- ב-Android 14, אם זמן הריצה של ה-SDK מסתיים בזמן שערכות ה-SDK נטענו, ואם מפתח האפליקציה לא רשם את שיטות ה-callback של מחזור החיים שצוינו למעלה, האפליקציה מסתיימת כברירת מחדל. רק תהליכי האפליקציה שטענו ערכות SDK מסתיימים ויוצאים באופן תקין.
- קישור אובייקטים שהוחזרו על ידי ה-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), לא יתמכו בזמן הריצה של ה-SDK בגלל ההשפעה על תקינות המערכת. בקרוב צריכות לעמוד בדרישות המינימליות הנחוצות כדי להשתמש בהצלחה בזמן הריצה של ה-SDK.
תקשורת
מכיוון שאפליקציות ו-SDKs פועלים כרגע באותו תהליך, התקשורת ביניהם היא ללא הגבלות וללא תיווך. בנוסף, Android מאפשר גם בתוך אפליקציות תקשורת גם אם התקשורת מתחילה ומסתיימת בערכות SDK. מודל התקשורת הפתוח הזה מאפשר תרחישים לדוגמה שונים, ובמקביל מאפשר שיתוף נתונים לא גלויים בין אפליקציות ובין ערכות SDK בתוך אפליקציות ובין אפליקציות. אנחנו מציעים את העדכונים הבאים כדי את מודל התקשורת הזה מנסה לאזן בין הערך של והגשמת המטרות שקבענו.
אפליקציה ל-SDK
הממשק בין האפליקציה ל-SDK הוא נתיב התקשורת הנפוץ ביותר ל-SDK, ו-API של SDK הוא המקום שבו וחדשנות יש. אנחנו שואפים לשמר את היכולת של ערכות ה-SDK לחדש ולהבדיל את עצמן. כתוצאה מכך, ההצעה שלנו מאפשרת לערכות SDK לחשוף ממשקי API , ולוודא שהאפליקציות יפיקו תועלת מכל החידושים האלה.
בהתחשב במבנה גבולות התהליך של זמן הריצה של ה-SDK, אנחנו מציעים ליצור שכבת תכנון שניתן לגשת אליה מתוך האפליקציה, כדי להעביר את הקריאות ל-API תגובות או קריאות חוזרות (callback) מעבר לגבול הזה בין האפליקציה ל-SDK. אנחנו בטענה שהממשק לשכבת התכנון הזו יוגדר על ידי SDK שנוצר על ידי כלי build רשמיים בקוד פתוח, עד עכשיו.
במסגרת ההצעה הזו אנחנו שואפים להסיר מהאפליקציה את תהליך התכנון הסטנדרטי ומפתחי SDK, תוך מתן גמישות למפתחי ה-SDK שקוד ה-SDK פועל בזמן הריצה של ה-SDK כדי לעמוד ביעדי הפרטיות שלנו. האם צריך את הנתיב הזה, השפה והכלים של הגדרת ה-API יצטרכו שמעוצב בהתאם לקלט שלכם.
מודל האינטראקציה הכללי ייראה כך:
- האפליקציה מפעילה את ה-SDK דרך הממשק ומעבירה קריאות חוזרות.
- ה-SDK מטפל בבקשות באופן אסינכררוני ומשיב באמצעות פונקציות ה-callbacks.
- אפשר להכליל את העיקרון הזה לכל מודל של בעל תוכן דיגיטלי ומנויים, כלומר אפליקציה יכולה להירשם לאירועים ב-SDK באמצעות פונקציות חזרה (callbacks), וכשהאירועים האלה מתרחשים, פונקציות החזרה מופעלות.
השלכות מהמבנה החדש של תהליכים שונים בהצעה הזו היא יש שני מחזורי חיים של תהליכים שצריך לנהל: אחד בשביל האפליקציה עצמו, והשני בשביל זמן הריצה של ה-SDK. ההצעה שלנו היא להפוך את התהליך הזה לאוטומטי ככל האפשר, כדי לצמצם את ההשפעה על מפתחי האפליקציות ומערכות ה-SDK. בתרשים הבא מוצגת גישה שאנחנו שוקלים:
הפלטפורמה תחשוף ממשקי API חדשים לאפליקציות כדי לטעון באופן דינמי ערכות SDK תהליך זמן ריצה ל-SDK, קבלת התראות על שינויים במצב התהליך וליצור אינטראקציה עם ערכות ה-SDK שנטענו בזמן הריצה של ה-SDK.
בתרשים הקודם מוצגת תקשורת בין האפליקציה ל-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ומעבירה אותו לממשק ה-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)
ההצעה שלנו היא ש-IBinder ו-requestSurfacePackage() API
כללי ולא מכוון שהאפליקציות יתקשרו אליו ישירות. במקום זאת,
תיקרא על ידי הפניית ה-API שנוצרה למעלה, באמצעות ספריית Shim
כדי להפחית את העומס על מפתחי האפליקציות.
SDK ל-SDK
שתי ערכות SDK באותה אפליקציה צריכות לתקשר לעתים קרובות. הדבר יכול להתרחש כאשר ערכות ה-SDK צריכות להיות מורכבות מערכות SDK, והוא יכול להתרחש אם ערכות SDK מגורמים שונים צריכות לשתף פעולה כדי למלא בקשה אפליקציית שיחות.
יש שני מקרים מרכזיים שכדאי להביא בחשבון:
- כששתי ערכות ה-SDK מופעלות בזמן ריצה. במקרה הזה, שתי ערכות ה-SDK פועלות
זמן הריצה ל-SDK עם כל ההגנות שלו. ערכות SDK לא יכולות לתקשר בתור
שהם עושים היום באפליקציה. כתוצאה מכך, API ב-
SdkSandboxControllerנוסף כדי לאפשר את האחזורSandboxedSdkאובייקטים לכל ערכות ה-SDK מחדש שנטענו. כך ל-RE-SDK יש אפשרות לתקשר עם ערכות 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 (זמינה ב- התצוגה המקדימה העדכנית למפתחים)
- איך תצוגות ורינדור מרחוק צריכים לפעול בתהליך בחירת הרשת (הצעה ב- פיתוח)
התרחישים הבאים לדוגמה נלקחים בחשבון במהלך תכנון הפרימיטיבים:
- תהליך בחירת הרשת (Mediation) ובידינג. ערכות SDK רבות לפרסום מציעות תהליך בחירת רשת (Mediation) או בידינג יכולת שמאפשרת ל-SDK להפעיל ערכות SDK אחרות כדי להשיג חשיפה של מודעה (תהליך בחירת הרשת) או לצורך איסוף אותות כדי לנהל מכרז (בידינג). בדרך כלל ה-SDK המתאם קורא לערכות SDK אחרות באמצעות מתאם שמרוהט על ידי תיאום בין ה-SDK. בהתחשב בפרימיטיביות שפורטו למעלה, ה-SDK התואם, RE או לא, צריכים להיות מסוגלים לגשת לכל ערכות ה-SDK מסוג RE ולא של RE לצורך פעולה רגילה. הרינדור בהקשר הזה הוא תחום פעיל בחקירה.
- גילוי תכונות. מוצרי SDK מסוימים כוללים ערכות SDK קטנות יותר, בתהליך של גילוי בין ערכות SDK, כדי לקבוע מהי קבוצת התכונות האולטימטיבית שנחשף למפתח האפליקציה. עקרונות בסיסיים של רישום וגילוי צפויות לאפשר את התרחיש לדוגמה הזה.
- מודלים של מינויים לבעלי תוכן דיגיטלי. לחלק מערכות ה-SDK יש בעל אפליקציה של אירועים שערכות SDK או אפליקציות אחרות יכולות להירשם אליהם באמצעות התקשרות חזרה. הרכיבים הבסיסיים שלמעלה אמורים לתמוך בשימוש הזה מותאמת אישית.
אפליקציה לאפליקציה
תקשורת בין אפליקציות היא תהליך שבו לפחות אחד משני התהליכים מתקיימים היא ערכת 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.
- תקציר אישורים: תקציר האישורים של גרסת ה-build של ה-SDK. אנחנו ממליצים למפתח ה-SDK לקבל את הערך הזה ולרשום אותו בחנות האפליקציות הרלוונטית לכל גרסה של ה-build.
המדיניות הזו חלה רק על ערכות SDK שמופצות בחנות אפליקציות, בין אם מדובר ב-RE ובין אם לא. כדי לקשר אפליקציות עם ערכות SDK סטטיות, ייעשה שימוש במנגנונים הקיימים של תלות.
מכיוון שהמטרה שלנו היא להשפיע על המפתחים במינימום, חשוב שברגע שמציינים את רמת ה-API היעד שתומכת בסביבת זמן הריצה של ה-SDK, למפתחי האפליקציות תמיד תהיה גרסה build אחת בלבד, בין שהיא פועלת במכשירים שתומכים בסביבת זמן הריצה של ה-SDK ובין שלא.
מפתחי SDK
בתכנון שאנחנו מציעים, מפתחי RE SDK צריכים במפורש להצהיר במניפסט על רכיב חדש שמייצג את ישות ה-SDK או הספרייה. בנוסף, קבוצת ערכים דומה לזו של התלות סופקו בתוספת גרסה משנית:
- שם: שם החבילה של ה-SDK או הספרייה.
- גרסה ראשית: קוד הגרסה הראשית של ה-SDK.
- גרסה משנית: קוד הגרסה המשנית של ה-SDK.
אם למפתחי SDK של RE יש ערכות SDK אחרות של RE כיחסי תלות בזמן ה-build, סביר להניח שהם יצטרכו להצהיר עליהן באופן זהה לאופן שבו מפתח אפליקציות יצהיר על אותו יחסי תלות. ערכות SDK של RE שתלויה בערכות SDK שאינן של RE יקשרו אותן באופן סטטי. אם ערכות ה-SDK שאינן ל-RE דורשות פונקציונליות ש-SDK Runtime לא תומך בה, או אם הן צריכות לפעול בתהליך של האפליקציה, הדבר עלול לגרום לבעיות שיזוהו בזמן ה-build או במהלך תהליכי הבדיקה.
סביר להניח שמפתחי RE SDK ירצו להמשיך לתמוך בערכות שלא הופעלו מחדש מכשירים, כמו Android מגרסה 12 ומטה, וכפי שמצוין בתקינות המערכת של המסמך, מכשירי Android 13 ברמה בסיסית ומשאבי מערכת מוגבלים. אנחנו מפתחים גישות כדי להבטיח SDK מפתחים יכולים לשמור על בסיס קוד יחיד כדי לתמוך בסביבות RE ובסביבות אחרות.
גרסאות build
מפתחי אפליקציות
אנחנו מצפים שמפתחי אפליקציות יחוו שינוי קטן שלב ה-build. יחסי התלות ב-SDK, בין שהם מופצים באופן מקומי ובין שהם מופצים בחנות האפליקציות (RE או לא), צריכים להיות קיימים במכונה כדי לבצע בדיקות איות, הידור וגרסאות build. אנחנו מציעים ש-Android Studio יפשט את הנושאים האלה פרטים ממפתח האפליקציה עם שימוש רגיל, תוך שקיפות מלאה ככל האפשר.
אנחנו מצפים שגרסת build ל-DEBUG תכלול את כל הקוד והסמלים שצריכים להופיע בגרסת build ל-DEBUG כדי שניתן יהיה לנפות בה באגים. לעומת זאת, בגרסת build ל-RELEASE אפשר להסיר מהארטיפקט הסופי את כל ערכות ה-SDK שחולקו בחנות האפליקציות (עם RE או בלי).
אנחנו עדיין בשלב מוקדם של תכנון האפשרות הזו, ונשתף פרטים נוספים בהמשך.
מפתחי SDK
אנחנו מפתחים נתיב שיבטיח שגרסאות שאינן RE ו-RE של SDK יכול להיות מובנה בארטיפקט אחד להפצה. כך מפתחי האפליקציות לא יצטרכו לתמוך בגרסאות build נפרדות של SDK ל-RE ולגרסאות אחרות.
בדומה לאפליקציות, כל ערכות ה-SDK של יחסי התלות שמופצות בחנות האפליקציות צריכות להיות במכונה לצורך איתור שגיאות בקוד, הידור ויצירת גרסאות build, ואנחנו מצפים ש-Android Studio תאפשר לעשות זאת בצורה חלקה.
בדיקה
מפתחי אפליקציות
כפי שמתואר בהצעה שלנו, מפתחי האפליקציות יוכלו לבדוק את האפליקציות שלהם במכשירים עם Android 13 כרגיל. אחרי שהם יצרו ניתן יהיה להתקין את האפליקציה במכשיר RE או באמולטור RE. תהליך ההתקנה הזה יבטיח שערכות ה-SDK הנכונות יותקנו בסביבת זמן הריצה של ה-SDK למכשיר או למהדמator, בין שהן נשלפו ממאגר SDK מרוחק ובין שהן נשלפו מהמטמון של מערכת ה-build.
מפתחי SDK
בדרך כלל, מפתחי SDK משתמשים באפליקציות בדיקה פנימיות במכשירים ובמכונות וירטואליות כדי לבדוק את הפיתוח שלהם. ההצעה שלנו לא משנה את זה, וגם אימות בתוך האפליקציה יכלול את אותם השלבים שמתוארים למפתחי אפליקציות שלמעלה, באמצעות ארטיפקט אחד ל-build לאפליקציות 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 של Analytics שבהן המשתמש ניתן ליצור קבוצות למטרות הבאות: טירגוט, ערכות SDK להצגת מודעות, מניעת ניצול לרעה וערכות SDK למניעת הונאה של מודעות, ערכות SDK של מעורבות וערכות SDK לשיוך.
-
האם כל ערכת SDK יכולה לפעול בזמן הריצה של ה-SDK?
למרות שהמיקוד הראשוני הוא בערכות SDK שקשורות למודעות, מפתחים של ערכות SDK שאינן קשורות למודעות, למצוא סביבה שמוגנת בשמירה על הפרטיות, והם מאמינים שהם יכולים לפעול במסגרת בעזרת התנאים שצוינו למעלה אפשר לשתף משוב על ערכות ה-SDK שלהן בזמן הריצה של ה-SDK. זמן הריצה של ה-SDK לא תוכנן להיות תואם בכל העיצובים של ה-SDK. מעבר למגבלות המתועדות, סביר להניח שזמן הריצה ל-SDK לא מתאים ל-SDKs שצריכים תקשורת בזמן אמת או תקשורת עם תפוקה גבוהה עם אפליקציית האירוח.
-
למה כדאי לבחור בביצוע בידוד של תהליכים במקום בידוד בזמן הריצה של Java בתהליך?
בשלב זה, סביבת זמן הריצה שמבוססת על Java לא מאפשרת בקלות להגדיר את גבולות האבטחה הנדרשים כדי להבטיח את הפרטיות של משתמשי Android. סביר להניח שניסיון להטמיע משהו כזה ידרוש מאמץ של כמה שנים, ללא ערובה להצלחה. לכן, ארגז החול לפרטיות משתמש בגבולות של תהליכי שימוש, טכנולוגיה מוכחת ומובנת.
-
האם העברת ערכות ה-SDK לתהליך זמן הריצה של ה-SDK תאפשר לחסוך בגודל ההורדה או במרחב האחסון?
אם כמה אפליקציות משולבות עם ערכות SDK שפועלות בזמן ריצה מאותה גרסת, אפשר לצמצם את גודל ההורדה ואת נפח האחסון בדיסק.
-
איזה סוג של אירועים במחזור החיים של האפליקציה, למשל כשהאפליקציה עוברת רקע כללי, האם לערכות SDK תהיה גישה בזמן הריצה ל-SDK?
אנחנו עובדים בשיא המרץ על תמיכה בתכנון של התראות בסביבת זמן הריצה של ה-SDK לגבי אירועים במחזור החיים של אפליקציית הלקוח ברמת האפליקציה (למשל, האפליקציה עוברת לרקע, האפליקציה עוברת לחזית). העיצוב והקוד לדוגמה ישותפו בתצוגה מקדימה למפתחים שתהיה בקרוב.
מומלץ עבורך
- הערה: טקסט הקישור מוצג כאשר JavaScript מושבת
- מדריך למפתחים בנושא זמן ריצה ל-SDK