ב-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). אם אתם זקוקים להתנהגות הישנה, עליכם להשתמש בקוד מקומי.