שינויים בהתנהגות: אפליקציות שמטרגטות ל-Android 14 ואילך

בדומה לגרסאות קודמות, Android 14 כולל שינויים בהתנהגות שעשויים להשפיע על האפליקציה שלכם. שינויי ההתנהגות הבאים רלוונטיים רק לאפליקציות שמטרגטות את Android 14 (רמת API‏ 34) ומעלה. אם האפליקציה שלכם מטרגטת את Android מגרסה 14 ואילך, אתם צריכים לשנות את האפליקציה כדי שהיא תתמוך בהתנהגויות האלה בצורה נכונה, במקרים הרלוונטיים.

חשוב גם לבדוק את רשימת השינויים בהתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 14, בלי קשר ל-targetSdkVersion של האפליקציה.

פונקציונליות עיקרית

חובה לציין את סוגי השירותים שפועלים בחזית

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

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

אכיפה של ההרשאה BLUETOOTH_CONNECT ב-BluetoothAdapter

Android 14 enforces the BLUETOOTH_CONNECT permission when calling the BluetoothAdapter getProfileConnectionState() method for apps targeting Android 14 (API level 34) or higher.

This method already required the BLUETOOTH_CONNECT permission, but it was not enforced. Make sure your app declares BLUETOOTH_CONNECT in your app's AndroidManifest.xml file as shown in the following snippet and check that a user has granted the permission before calling getProfileConnectionState.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

עדכונים ל-OpenJDK 17

Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.

A few of these changes can affect app compatibility:

  • Changes to regular expressions: Invalid group references are now disallowed to more closely follow the semantics of OpenJDK. You might see new cases where an IllegalArgumentException is thrown by the java.util.regex.Matcher class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle the DISALLOW_INVALID_GROUP_REFERENCE flag using the compatibility framework tools.
  • UUID handling: The java.util.UUID.fromString() method now does more strict checks when validating the input argument, so you might see an IllegalArgumentException during deserialization. To enable or disable this change while testing, toggle the ENABLE_STRICT_VALIDATION flag using the compatibility framework tools.
  • ProGuard issues: In some cases, the addition of the java.lang.ClassValue class causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whether Class.forName("java.lang.ClassValue") returns a class or not. If your app was developed against an older version of the runtime without the java.lang.ClassValue class available, then these optimizations might remove the computeValue method from classes derived from java.lang.ClassValue.

‫JobScheduler מחזק את ההתנהגות של קריאות חוזרות (callback) ושל הרשת

מאז ההשקה של התכונה JobScheduler, מצפה שהאפליקציה תחזור מ- onStartJob או onStopJob בתוך כמה שניות. לפני Android 14, אם משימה מסוימת נמשכת יותר מדי זמן, היא מופסקת ונכשלה באופן שקט. אם האפליקציה שלכם מטרגטת ל-Android 14 (רמת API 34) ואילך וחרגה מהזמן שהוקצה לשרשור הראשי, האפליקציה תפעיל אירוע ANR עם הודעת השגיאה 'No response to onStartJob' או 'No response to onStopJob'.

שגיאת ה-ANR הזאת יכולה לנבוע מ-2 תרחישים: 1. יש עבודה שחוסמת את ה-thread הראשי, ומונעת את ההפעלה וההשלמה של פונקציות ה-callbacks onStartJob או onStopJob במסגרת מגבלת הזמן הצפויה. 2. המפתח מפעיל עבודה חוסמת בתוך פונקציית ה-callback onStartJob או onStopJob של JobScheduler, וכתוצאה מכך פונקציית ה-callback לא מסתיימת במסגרת מגבלת הזמן הצפויה.

כדי לטפל בבעיה מס' 1, צריך לנפות באגים ולבדוק מה חוסם את ה-thread הראשי כשמתרחש ה-ANR. אפשר לעשות זאת באמצעות ApplicationExitInfo#getTraceInputStream() כדי לקבל את הטראס של tombstone כשמתרחש ה-ANR. אם מצליחים לשחזר את שגיאת ה-ANR באופן ידני, אפשר לתעד מעקב אחר המערכת ולבדוק את המעקב באמצעות Android Studio או Perfetto כדי להבין טוב יותר מה פועל ב-thread הראשי כשמתרחשת ה-ANR. חשוב לזכור שזה יכול לקרות כשמשתמשים ב-JobScheduler API ישירות או באמצעות ספריית androidx WorkManager.

כדי לטפל בבעיה השנייה, כדאי לעבור ל-WorkManager, שמספק תמיכה באריזת כל עיבוד ב-onStartJob או ב-onStopJob בשרשור אסינכרוני.

JobScheduler גם כולל דרישה להצהיר על הרשאת ACCESS_NETWORK_STATE אם משתמשים ב-setRequiredNetworkType או אילוץ של setRequiredNetwork. אם האפליקציה לא מצהירה על ההרשאה ACCESS_NETWORK_STATE כשמגדירים את התזמון של המשימה, והיא מטרגטת את Android מגרסה 14 ואילך, תופיע הודעת השגיאה SecurityException.

Tiles launch API

For apps targeting 14 and higher, TileService#startActivityAndCollapse(Intent) is deprecated and now throws an exception when called. If your app launches activities from tiles, use TileService#startActivityAndCollapse(PendingIntent) instead.

פרטיות

גישה חלקית לתמונות ולסרטונים

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

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

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

חוויית משתמש

התראות מאובטחות לגבי Intent במסך מלא

With Android 11 (API level 30), it was possible for any app to use Notification.Builder.setFullScreenIntent to send full-screen intents while the phone is locked. You could auto-grant this on app install by declaring USE_FULL_SCREEN_INTENT permission in the AndroidManifest.

Full-screen intent notifications are designed for extremely high-priority notifications demanding the user's immediate attention, such as an incoming phone call or alarm clock settings configured by the user. For apps targeting Android 14 (API level 34) or higher, apps that are allowed to use this permission are limited to those that provide calling and alarms only. The Google Play Store revokes default USE_FULL_SCREEN_INTENT permissions for any apps that don't fit this profile. The deadline for these policy changes is May 31, 2024.

This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off.

You can use the new API NotificationManager.canUseFullScreenIntent to check if your app has the permission; if not, your app can use the new intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT to launch the settings page where users can grant the permission.

אבטחה

הגבלות על אובייקטים מרומזים של Intent ועל אובייקטים של Intent בהמתנה

For apps targeting Android 14 (API level 34) or higher, Android restricts apps from sending implicit intents to internal app components in the following ways:

  • Implicit intents are only delivered to exported components. Apps must either use an explicit intent to deliver to unexported components, or mark the component as exported.
  • If an app creates a mutable pending intent with an intent that doesn't specify a component or package, the system throws an exception.

These changes prevent malicious apps from intercepting implicit intents that are intended for use by an app's internal components.

For example, here is an intent filter that could be declared in your app's manifest file:

<activity
    android:name=".AppActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.action.APP_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

If your app tried to launch this activity using an implicit intent, an ActivityNotFoundException exception would be thrown:

Kotlin

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

Java

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

To launch the non-exported activity, your app should use an explicit intent instead:

Kotlin

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

Java

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

מקלטי שידורים שרשומים בזמן ריצה חייבים לציין את התנהגות הייצוא

Apps and services that target Android 14 (API level 34) or higher and use context-registered receivers are required to specify a flag to indicate whether or not the receiver should be exported to all other apps on the device: either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED, respectively. This requirement helps protect apps from security vulnerabilities by leveraging the features for these receivers introduced in Android 13.

Exception for receivers that receive only system broadcasts

If your app is registering a receiver only for system broadcasts through Context#registerReceiver methods, such as Context#registerReceiver(), then it shouldn't specify a flag when registering the receiver.

טעינה בטוחה יותר של קוד דינמי

If your app targets Android 14 (API level 34) or higher and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

If you must dynamically load code, use the following approach to set the dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon as the file is opened and before any content is written:

Kotlin

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

Java

File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

Handle dynamically-loaded files that already exist

To prevent exceptions from being thrown for existing dynamically-loaded files, we recommend deleting and recreating the files before you try to dynamically load them again in your app. As you recreate the files, follow the preceding guidance for marking the files read-only at write time. Alternatively, you can re-label the existing files as read-only, but in this case, we strongly recommend that you verify the integrity of the files first (for example, by checking the file's signature against a trusted value), to help protect your app from malicious actions.

הגבלות נוספות על התחלת פעילויות מהרקע

For apps targeting Android 14 (API level 34) or higher, the system further restricts when apps are allowed to start activities from the background:

These changes expand the existing set of restrictions to protect users by preventing malicious apps from abusing APIs to start disruptive activities from the background.

פרצת אבטחה מסוג Path Traversal בקובץ ZIP

For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip Path Traversal Vulnerability in the following way: ZipFile(String) and ZipInputStream.getNextEntry() throws a ZipException if zip file entry names contain ".." or start with "/".

Apps can opt-out from this validation by calling dalvik.system.ZipPathValidator.clearCallback().

באפליקציות שמיועדות ל-Android 14 (רמת API ‏34) ואילך, MediaProjection#createVirtualDisplay יוצרת את השגיאה SecurityException באחת מהתרחישים הבאים:

האפליקציה שלכם צריכה לבקש מהמשתמש להביע הסכמה לפני כל סשן צילום. סשן צילום יחיד הוא קריאה יחידה ל-MediaProjection#createVirtualDisplay, וצריך להשתמש בכל מכונה של MediaProjection רק פעם אחת.

טיפול בשינויים בתצורה

אם האפליקציה צריכה להפעיל את MediaProjection#createVirtualDisplay כדי לטפל בשינויים בתצורה (כמו שינוי כיוון המסך או גודל המסך), תוכלו לפעול לפי השלבים הבאים כדי לעדכן את VirtualDisplay למכונה הקיימת של MediaProjection:

  1. קוראים ל-VirtualDisplay#resize עם הרוחב והגובה החדשים.
  2. מספקים Surface חדש עם הרוחב והגובה החדשים ל-VirtualDisplay#setSurface.

רישום של קריאה חוזרת

האפליקציה צריכה לרשום קריאה חוזרת (callback) כדי לטפל במקרים שבהם המשתמש לא נותן הסכמה להמשך סשן הצילום. כדי לעשות זאת, מטמיעים את Callback#onStop ומאפשרים לאפליקציה לשחרר את המשאבים הקשורים (כמו VirtualDisplay ו-Surface).

אם האפליקציה לא תירשם את קריאת החזרה (callback) הזו, MediaProjection#createVirtualDisplay תשליך IllegalStateException כשהאפליקציה תפעיל אותה.

הגבלות שאינן קשורות ל-SDK עודכנו

Android 14 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 14, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 14. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.