קביעות משופרות במכשירי Android מגרסה 13 ואילך

לאחרונה הודענו על שיפורים בממשק Play Integrity API, שכוללים קביעות מהירות יותר, עמידות יותר בפני התקפות ופרטיות משופרת למשתמשים, לצד שיפורים נוספים באבטחה.

סיכום השינויים

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

• שילובים חדשים: כל השילובים החדשים יקבלו את התוצאות החדשות באופן אוטומטי.

• שילוב קיים עד מאי 2025: מפתחים עם שילובים קיימים יכולים להביע הסכמה בדף ההגדרות של Play Integrity API ב-Play Console כדי לקבל את הקביעות החדשות לצד הקביעות הקודמות כבר עכשיו, וכך יהיה להם זמן לבדוק את הקביעות ולשקול לבצע שינויים בהתנהגות האפליקציה. לפני שמביעים הסכמה, אפשר לראות את השינוי הצפוי באחוז המכשירים שמחזירים כל אחד מהפסק הדין ודוגמה ל-JSON של פסק הדין החדש. אחרי שתביעו הסכמה, תקבלו בתשובה שני שדות נוספים עם גרסת ה-Android SDK וקביעות התקינות הקודמות.

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

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

שאלות נפוצות

סקירה כללית

מהו Play Integrity API?

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

אילו אותות מספק Play Integrity API?

Play Integrity API כולל את הזהות של האפליקציה המבקשת, את העובדה שהאפליקציה המבקשת הותקנה על ידי Google Play ואת העובדה שהמכשיר הוא מכשיר Android מקורי שקיבל אישור של Play Protect. האותות האלה מוצגים כברירת מחדל. אתם יכולים לקרוא את האותות האלה בשרת הקצה העורפי של האפליקציה ולהחליט אם האפליקציה צריכה להגיב ואיך היא צריכה להגיב. מפתחים ב-Google Play יכולים להביע הסכמה לקבלת אותות נוספים בהתקנות שלהם ב-Play כדי לראות מידע נוסף.

מהו אימות עם מפְתח של פלטפורמת Android?

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

שינויים בפסק הדין

אילו שינויים מתבצעים בקביעות של Play Integrity API במכשירים עם Android 13 ואילך?

מעכשיו, Play Integrity API ידרוש אותות אבטחה ברמת החומרה לכל קביעות התקינות:

• התוצאה של זיהוי המכשיר meets-device-integrity מציינת שהמכשיר שבו פועלת האפליקציה הוא מכשיר Android מקורי שתואם ל-Play Protect. כדי לקבל את התוצאה הזו, תוכנת האתחול של המכשיר צריכה להיות נעולה ומערכת ההפעלה של Android שהוטענה צריכה להיות קובץ אימג' מאושר של יצרן המכשיר.
• תוצאת זיהוי המכשיר meets-strong-integrity מציינת מכשיר Android מקורי שתואם ל-Play Protect עם עדכון אבטחה עדכני. כדי לקבל את התוצאה הזו, צריך meets-device-integrity ושהמכשיר יקבל עדכון אבטחה בשנה האחרונה. התנאי הזה עשוי להשתנות בעתיד.
• התוצאה של זיהוי המכשיר meets-basic-integrity מציינת שהבדיקה התבצעה במכשיר פיזי עם Android. אפשר לנעול או לבטל את הנעילה של תוכנת האתחול של המכשיר, ואפשר לאמת או לבטל את האימות של מצב האתחול. יכול להיות שהוא לא מאושר על ידי Play Protect. במקרה כזה, Google לא יכולה לספק ערבויות לגבי אבטחה, פרטיות או תאימות לאפליקציות, ולא יכולה להבטיח שהמכשיר לא פועל כשרתיף, למשל למכונה וירטואלית של Android. המשמעות היא גם שמכשירים עם הרשאת root יכולים להחזיר את הערך meets-basic-integrity כל עוד מתבצע אימות מפתחות.

השינויים האלה לא משפיעים על Play Integrity API ב-Play Games למחשב, שימשיך להחזיר את הערך meets-virtual-integrity.

למה קביעות התקינות של Play Integrity API משתנות במכשירים עם Android 13 ואילך?

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

• הפחתה של כ-90% באותות מהמכשיר שצריך לאסוף ולהעריך כדי ליצור את ההחלטה שמוגדרת כברירת מחדל בשרתים של Google. כדי להשתמש באותות אופציונליים, עדיין יהיה צורך באיסוף אותות נוספים.
• שיפור זמן האחזור של תוצאת הבדיקה ב-80% במקרה הגרוע ביותר של בקשות רגילות, וב-80% בכל הבקשות הקלאסיות לקבלת תוצאת ברירת המחדל. אותות אופציונליים עלולים להאריך את זמן האחזור.
• רמה עקבית של אמינות ותמיכה בכל גורמי הצורה של Android עם אימות מפתחות, כולל טלפונים ניידים, טאבלטים, מכשירים מתקפלים, טלוויזיות, כלי רכב, Wear OS ו-ChromeOS.
• הבחנה גדולה יותר בין כל תווית מכשיר בהחלטה לגבי זיהוי המכשיר: meets-strong-integrity,‏ meets-device-integrity ו-meets-basic-integrity.

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

אין שינוי בהחלטות של Play Integrity API ב-Play Games למחשב, והן יהיו זהות ב-Android 12 וגרסאות קודמות כמו ב-Android 13 וגרסאות מתקדמות יותר.

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

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

val deviceIntegrity =
  JSONObject(payload).getJSONObject("deviceIntegrity")
val sdkVersion =
  if (deviceIntegrity.has("deviceAttributes")) {
    deviceIntegrity.getJSONObject("deviceAttributes").getInt("sdkVersion")
  } else {
    0
  }

if (sdkVersion >= 30) {
  // Provide Android R+ specific experience to the user.
}

JSONObject deviceIntegrity =
  new JSONObject(payload).getJSONObject("deviceIntegrity");
int sdkVersion =
  deviceIntegrity.has("deviceAttributes")
    ? deviceIntegrity.getJSONArray("deviceAttributes").getInt("sdkVersion")
    : 0;

if (sdkVersion >= 30) {
  // Provide Android R+ specific experience to the user.
}

איך אפשר להשתמש בהגדרת התווית הישנה meets-strong-integrity בכל גרסאות Android SDK?

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

val deviceRecognitionVerdict =
  if (deviceIntegrity.has("deviceRecognitionVerdict")) {
    deviceIntegrity.getJSONArray("deviceRecognitionVerdict").toString()
  } else {
    ""
  }

val deviceIntegrityToCheckFor =
  sdkVersion < 33 ? "MEETS_STRONG_INTEGRITY" : "MEETS_DEVICE_INTEGRITY";

if (deviceRecognitionVerdict.contains(deviceIntegrityToCheckFor)) {
  // Looks good!
}

JSONObject deviceIntegrity =
  new JSONObject(payload).getJSONObject("deviceIntegrity");
String deviceRecognitionVerdict =
  deviceIntegrity.has("deviceRecognitionVerdict")
    ? deviceIntegrity.getJSONArray("deviceRecognitionVerdict").toString()
    : "";

String deviceIntegrityToCheckFor =
  sdkVersion < 33 ? "MEETS_STRONG_INTEGRITY" : "MEETS_DEVICE_INTEGRITY";

if (deviceRecognitionVerdict.contains(deviceIntegrityToCheckFor)) {
  // Looks good!
}

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

אילו שינויים נוספים מתבצעים בקביעות הסטטוס של Play Integrity API?

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

• תגובה עם רישיון Play: כדי להחזיר תגובה עם רישיון Play, Play Integrity API מחייב עכשיו תמיד שהאפליקציה המבקשת תהיה מותקנת או מעודכנת על ידי Google Play. כך מתקנים מקרים קיצוניים מסוימים ומקלים על המפתחים לפרש את התגובה. התכונה הזו זמינה ב-Android מגרסה 13 ואילך.
• זמינות האותות האופציונליים: מעכשיו, כדי שכל האותות האופציונליים שזמינים למפתחים באמצעות Google Play Console או Play SDK Console יהיו זמינים, האפליקציה המבקשת צריכה להיות מותקנת או מעודכנת על ידי Google Play ב-Android מגרסה 13 ואילך. הנתונים האלה כוללים את meets-strong-integrity,‏ meets-basic-integrity, הפעילות האחרונה במכשיר, את התוצאה של בדיקת הסיכון לגישה לאפליקציה ואת התוצאה של Play Protect. כל שאר הבקשות ל-Play Integrity API יהיו סטנדרטיות, כדי לקבל את בדיקת המכשיר (עם התווית meets-device-integrity בלבד), את בדיקת מנהל ההתקנות ואת בדיקת תקינות האפליקציה.
• שינויים בקביעות לגבי מכשירים ספציפיים: Play Integrity API יתחיל גם לשנות באופן אוטומטי את הקביעות לגבי מכשירים בתרחישים נוספים כדי להגן על האפליקציות בשלב מוקדם יותר בכל הגרסאות של Android SDK, למשל כשיש ראיות לפעילות מוגזמת או לפריצה למפתח. התכונה הזו תכלול את היכולת של Play לעבור לאותות אחרים כדי ליצור עבור המשתמשים החלטות זמניות לגבי המכשיר במקרים שבהם אותות שמגובים בחומרה לא זמינים. כדי לפתור בעיות שקשורות לפסיקה לגבי תקינות האפליקציה, מומלץ למפתחים להשתמש בתיבות הדו-שיח של Play לתיקון באפליקציה או להפנות את המשתמשים אל אפליקציית Play Store. עם הזמן, תיבת הדו-שיח הזו תטפל בתרחישים נוספים ותכלול הנחיות ספציפיות למשתמשים, שמציינות מה עליהם לתקן בהתאם למכשיר או לחשבון הספציפי שלהם.

הצטרפות וביטול הצטרפות

איך מצטרפים לקביעת התקינות המשופרת במכשירים עם Android מגרסה 13 ואילך?

מפתחים שמשתמשים ב-Play Console יכולים להביע הסכמה בדף ההגדרות של Play Integrity API.

מה יקרה לתגובה מ-Play Integrity API אחרי שאאשר את ההסכמה?

אלה שלושת הדברים שיקרה אחרי שתאשרו את ההסכמה:

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

כששינויי התוצאה ייכנסו לתוקף בכל השילובים במאי 2025, כל האפליקציות שהביעו הסכמה יפסיקו לקבל את השדה legacyDeviceRecognitionVerdict.

איך מדווחים על בעיות שקשורות להחלטות לגבי תקינות?

כדי לדווח על בעיות בתשובות מ-Play Integrity API, בין אם מדובר בבעיות שקשורות לקביעות ההיסטוריות ובין אם בבעיות שקשורות לקביעות החדשות, פועלים לפי ההוראות שמפורטות בדף התמיכה.

האם אפשר לבטל את ההסכמה אחרי שמביעים הסכמה?

כן, אפשר לבטל את ההסכמה בדף ההגדרות של Play Integrity API.

זמינות

מה נדרש כדי ש-Play Integrity API יפעל?

כדי להשתמש ב-Play Integrity API, חנות Google Play ו-Google Play Services צריכים להיות מותקנים במכשיר, כולל במכשירי Android וב-Google Play Games למחשב. כדי להשתמש בבקשות קלאסיות, נדרשת גרסת Android 4.4 (רמת API‏ 19) ואילך, ובבקשות רגילות נדרשת גרסת Android 5.0 (רמת API‏ 21) ואילך. במכשירים עם Android מגרסה 13 ואילך (רמת API‏ 33 ואילך), ל-Play Integrity API תהיה עכשיו אותה רמת אמינות ותמיכה בכל גורמי הצורה של Android עם אימות מפתחות, כולל מכשירים ניידים, טאבלטים, מכשירים מתקפלים, טלוויזיות, Auto, Wear OS ו-ChromeOS.

למה יש ב-Play Integrity API קביעות שונות למכשירים שונים?

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

מהו מכשיר עם Android שקיבל אישור מ-Play Protect?

מכשיר Android מאושר Play Protect (נקרא גם מכשיר Android עם GMS) הוא מכשיר שבו פועלת תוכנה צפויה שעברה מאות בדיקות תאימות של Google, עומדת במודל האבטחה וההרשאות של Android ונשלחת עם חבילת התכונות של Google Play Protect למניעת תוכנות זדוניות. כש-Play Integrity API יכול לאמת שמכשיר הוא מכשיר Android מאושר של Play Protect, הוא יחזיר את התגובה meets-device-integrity בקביעת התקינות של זיהוי המכשיר.

מהו מכשיר meets-basic-integrity?

‏Play Integrity API מחזיר גם תגובה אופציונלית בפסיקה לגבי המכשיר, meets-basic-integrity. אם המכשיר מחזיר רק את התוצאה meets-basic-integrity בלי meets-device-integrity או meets-strong-integrity, סימן שלא ניתן לאמת את מערכת ההפעלה של Android, אבל אימות המפתחות קיים. המשמעות היא שהבדיקה התבצעה במכשיר פיזי עם Android, אבל Google לא יכולה להבטיח את האבטחה, הפרטיות או התאימות של האפליקציות במכשיר, ולא יכולה להבטיח שהמכשיר לא פועל כשרתיף, למשל למכונה וירטואלית של Android. בהתאם לתרחישי השימוש ולרמת הסיכונים של המפתחים, הם יכולים להחליט איך הם רוצים שהאפליקציה שלהם תפעל במכשירים האלה.

האם כל מפתח יכול להשתמש ב-Play Integrity API?

כן, כל מפתח Android יכול לשלוח בקשות ל-Play Integrity API כדי לקבל את קביעות התקינות שמוגדרות כברירת מחדל. מגבלת השימוש היא 10,000 בקשות ביום, ללא קשר לערוץ ההפצה. מפתחים שמפרסמים את האפליקציות שלהם ב-Google Play בנוסף לכל ערוץ הפצה אחר יכולים גם לבקש להגדיל את המכסה היומית שלהם.

האם כל מפתח יכול להשתמש באימות מפתחות של פלטפורמת Android?

כן, כל מפתח Android יכול להשתמש באימות מפתחות בפלטפורמת Android כדי לקבל רשומת אימות מפתחות, שאפשר לאמת באמצעות האישור הציבורי של מפתח הבסיס לאימות של Google. Play Integrity API מאפשר למפתחים ליהנות מהיתרונות של אימות מפתחות ותכונות נוספות, בלי כל המורכבות של שילוב עם אימות מפתחות בעצמם.

אכיפה

איך מפתחים משתמשים בפסקי הדין של Play Integrity API?

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

האם Play Integrity API חוסם משתמשים או מכשירים?

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

מה המשתמשים צריכים לעשות אם המכשיר שלהם נכשל בבדיקות המכשיר של Play Integrity API?

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