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

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

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

הערה: בנוסף לשינויים המפורטים בדף הזה, Android 10 יוצרים מספר גדול של שינויים והגבלות המבוססים על פרטיות, כולל הבאים:

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

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

הגבלות על ממשק שאינו SDK

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

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

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

למידע נוסף, ראו עדכונים לגבי הגבלות על ממשקים שאינם ב-SDK ב-Android 10 והגבלות על ממשקים שאינם ב-SDK.

ניווט באמצעות תנועות

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

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

NDK

ב-Android 10 נכללים השינויים הבאים ב-NDK.

אובייקטים משותפים לא יכולים להכיל העברות של טקסט

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

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

שינויים בספריות ביולוגיות ובנתיבי מקשר דינמי

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

  • /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
  • /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
  • /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
  • /system/bin/linker -> /apex/com.android.runtime/bin/linker

השינויים האלה יחולו גם על גרסאות 64-ביט של הקובץ, עם lib/ הוחלף בטקסט lib64/.

מטעמי תאימות, קישורי ה-symlink מסופקים בנתיבים הישנים. לדוגמה, /system/lib/libc.so הוא קישור סימבולי אל /apex/com.android.runtime/lib/bionic/libc.so. ככה. dlopen(“/system/lib/libc.so”) ימשיך לפעול, אבל אפליקציות עוד ימצאו את ההבדל כאשר הם מנסים בפועל לבדוק את הספריות שנטענות על ידי קריאה /proc/self/maps או תוצאות דומות, וזה לא השגרה, אבל מצאנו את זה חלק מהאפליקציות עושות זאת כחלק מתהליך ההגנה שלהן על פריצה. אם כן, צריך להוסיף נתיבים של /apex/… כנתיבים חוקיים לקבצים של Binic.

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

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

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

Cause: execute-only (no-read) memory access error; likely due to data in .text.

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

אבטחה

מערכת Android 10 כוללת את שינויי האבטחה הבאים.

TLS 1.3 מופעל כברירת מחדל

ב-Android מגרסה 10 ואילך, TLS 1.3 מופעל כברירת מחדל לכל המכשירים חיבורי TLS. הנה כמה פרטים חשובים לגבי TLS 1.3 הטמעה:

  • אי אפשר להתאים אישית את סטים של אלגוריתמים להצפנה (cipher suite) TLS 1.3. סט אלגוריתמים להצפנה (cipher suite) נתמכים של TLS 1.3 תמיד מופעל כש-TLS 1.3 מופעל. כל ניסיון להשבית באמצעות התקשרות setEnabledCipherSuites() המערכת מתעלמת ממנו.
  • כשמתבצע משא ומתן על TLS 1.3, HandshakeCompletedListener האובייקטים מופעלים לפני שסשנים מתווספים למטמון של הסשן. (ב-TLS 1.2) ובגרסאות קודמות אחרות, האובייקטים האלה נקראים אחרי הוספת הסשנים למטמון של הסשן.)
  • במצבים מסוימים שבהם אירוע SSLEngine גורם SSLHandshakeException פועל הגרסאות הקודמות של Android, המקרים האלה גורמים SSLProtocolException במקום זאת ב-Android מגרסה 10 ואילך.
  • אי אפשר להשתמש במצב 0-RTT.

אם רוצים, אפשר לקבל SSLContext ש-TLS 1.3 מושבת בו. SSLContext.getInstance("TLSv1.2"). אפשר גם להפעיל או להשבית גרסאות פרוטוקול לכל חיבור בנפרד על ידי שיחה setEnabledProtocols() על אובייקט מתאים.

אישורים החתומים באמצעות SHA-1 לא נחשבים מהימנים ב-TLS

ב-Android 10, אישורים שמשתמשים באלגוריתם הגיבוב SHA-1 לא נחשבים מהימנים בחיבורי TLS. רשויות אישורים ברמה הבסיסית לא הנפיקו אישור כזה מאז 2016, והם כבר לא נחשבים כמהימנים ב-Chrome או בדפדפנים נפוצים אחרים.

כל ניסיון להתחבר ייכשל אם החיבור הוא לאתר שמציג לאישור באמצעות SHA-1.

שינויים ושיפורים בהתנהגות של KeyChain

דפדפנים מסוימים, כמו Google Chrome, מאפשרים למשתמשים לבחור אישור שרת TLS שולח הודעה עם בקשת אישור כחלק מלחיצת יד בפרוטוקול TLS. נכון לתאריך Android 10, אובייקטים של KeyChain מכבדים את המנפיקים פרמטרים של מפרט המקשים כאשר מפעילים את KeyChain.choosePrivateKeyAlias() ל- להציג למשתמשים בקשה לבחירת אישור. באופן ספציפי, ההנחיה הזו מכילים אפשרויות שלא פועלות בהתאם למפרטי השרת.

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

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

שינויים אחרים ב-TLS ובקריפטוגרפיה

בוצעו כמה שינויים קלים בספריות ה-TLS והקריפטוגרפיה ייכנסו לתוקף ב-Android 10:

  • הצפנים AES/GCM/NoPating ו-ChaCha20/Poly1305/NoP-# עוזרים להחזיר יותר מאגרי נתונים זמניים מדויקים מ-getOutputSize().
  • חבילת ההצפנה TLS_FALLBACK_SCSV מושמטת מניסיונות חיבור עם פרוטוקול מקסימלי של TLS 1.2 ומעלה. בזכות שיפורים בשרת ה-TLS אנו לא ממליצים לנסות חלופה חיצונית ל-TLS. במקום זאת, מומלץ להסתמך על משא ומתן לגבי גרסת ה-TLS.
  • ChaCha20-Poly1305 הוא כינוי ל-ChaCha20/Poly1305/NoP חלון.
  • שמות מארחים עם נקודות בסוף לא נחשבים לשמות מארחים מסוג SNI חוקיים.
  • התוסף Support_signature_algorithms ב-CertificateRequest הוא הוא נכון בעת בחירה של מפתח חתימה לתגובות לאישור.
  • ניתן להשתמש במפתחות חתימה אטומים, כמו אלה מ-Android Keystore, עם חתימות RSA-PSS ב-TLS.

שידורי Wi-Fi ישיר

ב-Android 10, השידורים הבאים קשורים ל-Wi-Fi ישירים לא במיקום קבוע:

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

יכולות של בקרת Wi-Fi

ב-Android 10 נוספה תמיכה כדי להקל על יצירה של שקע TCP/UDP באמצעות Wi-Fi Aware נתיבי נתונים. כדי ליצור שקע TCP/UDP שמתחבר אל ServerSocket, לקוח המכשיר צריך לדעת מה כתובת ה-IPv6 ומהיציאה של השרת. זה היה בעבר נדרשו להעביר אותן אל מחוץ למסגרת, למשל באמצעות שימוש ב-BT או בשכבת Wi-Fi Aware. 2 העברת הודעות, או זיהוי בתחום התדרים (in-band) באמצעות פרוטוקולים אחרים, כמו mDNS. ב- ב-Android 10, אפשר להעביר את המידע כחלק מהגדרת הרשת.

השרת יכול לבצע את אחת מהפעולות הבאות:

  • צריך להפעיל ServerSocket ולהגדיר את היציאה לשימוש.
  • יש לציין את פרטי היציאה כחלק מבקשת רשת Wi-Fi Aware.

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

Kotlin

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

Java

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

לאחר מכן הלקוח מבצע בקשת רשת Wi-Fi Aware כדי לקבל את ה-IPv6 היציאה שסופקה על ידי השרת:

Kotlin

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

Java

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

SYSTEM_ALERT_WINDOW במכשירי Go

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

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

אם אפליקציה במכשיר Go שולחת אובייקט Intent עם הפעולה ACTION_MANAGE_OVERLAY_PERMISSION המערכת דוחה את הבקשה באופן אוטומטי ומעבירה את המשתמש מסך הגדרות שכתוב בו שההרשאה לא מורשית כי מאט את המכשיר. אם אפליקציה במכשיר Go מבצעת שיחה Settings.canDrawOverlays() השיטה תמיד מחזירה FALSE. שוב, ההגבלות האלה לא חלות על אפליקציות שקיבל את ההרשאה SYSTEM_ALERT_WINDOW לפני שהמכשיר שודרג ל-Android 10.

אזהרות לגבי אפליקציות שמטרגטות לגרסאות ישנות של Android

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

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

הוסרו סטים של אלגוריתמים להצפנה (cipher suite) מסוג SHA-2 CBC

סטים הבאים של אלגוריתמים להצפנה (cipher suite) מסוג SHA-2 CBC הוסרו מהפלטפורמה:

  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

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

שימוש באפליקציות

ב-Android 10 נכללים השינויים הבאים בהתנהגות של שימוש באפליקציות:

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

  • לכל אפליקציה בנפרד – ב-Android 10 אפשר להגדיר מצב תצוגה באפור לכל אפליקציה בנפרד.

  • מצב הסחת דעת לכל אפליקציה – ב-Android 10 אפשר להגדיר אפליקציות באופן סלקטיבי למצב 'הסחת דעת', שבו ההתראות שלהן מושבתות והן לא מופיעות כאפליקציות מוצעות.

  • השעיה והפעלה – ב-Android 10, לאפליקציות מושעות אין אפשרות להשמיע אודיו.

שינויים בחיבור HTTPS

אם אפליקציה שפועלת בה מערכת Android 10 מעבירה את null אל setSSLSocketFactory(), IllegalArgumentException מתרחשת. בגרסאות קודמות, העברת null אל setSSLSocketFactory() הייתה זהה להעברת המפעל שמוגדר כברירת מחדל הנוכחי.

ספריית android.preference הוצאה משימוש

ספריית android.preference הוצאה משימוש החל מגרסה Android 10. במקום זאת, מפתחים צריכים להשתמש בספריית ההעדפות של AndroidX, שחלק מ-Android Jetpack. למשאבים נוספים לסיוע בהעברה למפתחים, כדאי לבדוק את ההגדרות המעודכנות המדריך והדוגמה הציבורית שלנו אפליקציה ומסמכי עזר.

שינויים בספריית השירות של קובצי ZIP

ב-Android 10 נוספו השינויים הבאים לכיתות בחבילה java.util.zip, שמטפלת בקובצי ZIP. השינויים האלה גורמים להתנהגות הספרייה להיות עקבית יותר בין Android לפלטפורמות אחרות שמשתמשות ב-java.util.zip.

משאבת לניפוח

בגרסאות הקודמות, חלק מהשיטות בכיתה Inflater הניבו IllegalStateException אם הם הופעלו אחרי שיחה ל-end(). ב-Android 10, השיטות האלה גורמות NullPointerException במקום זאת.

ZipFile

ב-Android מגרסה 10 ואילך, ה-constructor של ZipFile מקבלת ארגומנטים מסוג File, int ו-Charset לא נותנת ZipException אם קובץ ה-ZIP שסופק לא מכיל קבצים.

ZipOutputStream

ב-Android 10 ואילך, השיטה finish() ב- ZipOutputStream לא זורקת ZipException אם הוא מנסה לכתוב שידור פלט לקובץ ZIP שלא מכיל קבצים.

שינויים במצלמה

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

צריך להגדיר במפורש באפליקציות שמטרגטות את רמת ה-API 24 ומעלה android:resizeableActivity ולספק את הפונקציונליות הנדרשת לטיפול ריבוי חלונות.

מעקב אחר השימוש בסוללה

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

לפני Android 10, נתוני השימוש בסוללה מתאפסים בכל פעם שהמכשיר מנותק מהחשמל, בלי קשר לשינוי מועט ברמת הסוללה.

הוצאה משימוש של Android Beam

ב-Android 10 אנחנו מוציאים משימוש באופן רשמי את Android Beam, תכונה ישנה יותר להתחלת שיתוף נתונים בין מכשירים באמצעות תקשורת מטווח קצר (NFC). אנחנו גם מוציאים משימוש כמה ממשקי NFC API קשורים. Android Beam נשאר היא זמינה באופן אופציונלי לשותפים של יצרני מכשירים שרוצים להשתמש בה, אבל היא לא בפיתוח פעיל. מערכת Android תמשיך לתמוך ברשתות NFC אחרות לעומת זאת, יכולות וממשקי API, ותרחישים לדוגמה כמו קריאה מתגים התשלומים ימשיכו לפעול כצפוי.

שינוי בהתנהגות של Java.math.BigDecimal.stripTrailingZeros()

BigDecimal.stripTrailingZeros() לא שומר יותר אפסים בסוף בתור במקרה שבו ערך הקלט הוא אפס.

שינויים בהתנהגות של java.util.regex.Matcher ו-Pattern

התוצאה של split() שונתה כך שלא תתחיל יותר עם String ריק ("") כשיש התאמה של אפס רוחב בתחילת הקלט. גם משפיעה על String.split(). לדוגמה, הפקודה "x".split("") מחזירה עכשיו {"x"} לעומת זאת, הוא היה בעבר כדי להחזיר את {"", "x"} בגרסאות ישנות יותר של Android. האפליקציה "aardvark".split("(?=a)" מחזירה עכשיו {"a", "ardv", "ark"} במקום {"", "a", "ardv", "ark"}.

גם התנהגות החריגות לגבי ארגומנטים לא חוקיים שופר:

  • appendReplacement(StringBuffer, String) זורקת עכשיו IllegalArgumentException במקום IndexOutOfBoundsException אם ההחלפה של String מסתיימת בתו לוכסן הפוך בודד, וזו הפרה של החוק. אותה החרגה תועבר עכשיו אם ה-String החלופי יסתיים ב-$. בעבר, לא נקבעה חריגה לתרחיש הזה.
  • replaceFirst(null) לא מתקשר יותר ל-reset() בMatcher אם מתקבלת NullPointerException עכשיו יזרק/ה NullPointerException גם כשיש לא נמצאה התאמה. בעבר, היא שודרה רק כאשר הייתה התאמה.
  • start(int group), end(int group) ו-group(int group) נותנים עכשיו הזדמנות נוספת כללי IndexOutOfBoundsException אם אינדקס הקבוצה מחוץ לתחום. בעבר, השיטות האלה הניבו ArrayIndexOutOfBoundsException.

זווית ברירת המחדל של GradientDrawable היא עכשיו TOP_BOTTOM

ב-Android 10, אם הגדרתם GradientDrawable ב-XML ולא מספקים מדידת זווית, הכיוון ההדרגתי ברירת המחדל היא TOP_BOTTOM זהו שינוי לעומת גרסאות קודמות של Android, שבהן ברירת המחדל הייתה LEFT_RIGHT

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

רישום ביומן של אובייקטים שעברו סריאליזציה באמצעות SUID שמוגדר כברירת מחדל

החל מ-Android 7.0 (רמת API 24), הפלטפורמה ביצעה תיקון לברירת המחדל serialVersionUID לביצוע פעולות סריאליות אובייקטים. התיקון הזה לא השפיע על אפליקציות שמטרגטות לרמת API 23 ומטה.

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

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

  • האפליקציה מטרגטת רמת API 23 ומטה.
  • מחלקה עוברת סריאליזציה.
  • המחלקה הסידורית משתמשת בברירת המחדל serialVersionUID, במקום ב- הגדרה מפורשת של serialVersionUID.
  • ערך ברירת המחדל serialVersionUID שונה מערך ברירת המחדל serialVersionUID יהיה אם האפליקציה מטרגטת לרמת API 24 ומעלה.

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

שינויים ב-Java.io.FileChannel.map()

החל מ-Android 10, אי אפשר להשתמש ב-FileChannel.map() עבור קבצים לא סטנדרטיים, כמו /dev/zero, שלא ניתן לשנות את הגודל שלהם באמצעות truncate(). לתמונה הקודמת גרסאות Android בלעו את השגיאה "errno" שהוחזרה על ידי truncate(), אבל ב-Android 10 נשלחת התראה על חריגת נתונים (IOIV). אם אתם זקוקים להתנהגות הישנה, עליכם להשתמש בקוד מקומי.