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

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

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

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

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

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

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

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

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