Изменения в поведении: приложения для Android 15 или более поздней версии.

Как и в предыдущих версиях, Android 15 включает изменения в поведении, которые могут повлиять на ваше приложение. Следующие изменения в поведении применяются исключительно к приложениям, ориентированным на Android 15 или выше. Если ваше приложение ориентировано на Android 15 или выше, вам следует внести в него изменения для корректной поддержки этих изменений, где это применимо.

Обязательно ознакомьтесь также со списком изменений в поведении, которые затрагивают все приложения, работающие на Android 15, независимо от targetSdkVersion вашего приложения.

Основная функциональность

Android 15 изменяет или расширяет различные основные возможности системы Android.

Изменения в работе служб переднего плана

Мы вносим следующие изменения в службы переднего плана в Android 15.

• Поведение времени ожидания службы синхронизации данных на переднем плане
• Новый тип приоритетной службы обработки мультимедиа
• Ограничения на широковещательные приемники BOOT_COMPLETED , запускающие службы приоритета
• Ограничения на запуск служб переднего плана, пока приложение имеет разрешение SYSTEM_ALERT_WINDOW

Поведение тайм-аута службы синхронизации данных на переднем плане

В Android 15 представлен новый режим тайм-аута для dataSync для приложений, предназначенных для Android 15 (уровень API 35) или выше. Это поведение также применимо к новому типу службы переднего плана mediaProcessing .

Система разрешает службам dataSync приложения работать в общей сложности 6 часов в течение 24-часового периода, после чего система вызывает метод Service.onTimeout(int, int) работающей службы (представленный в Android 15). В это время у службы есть несколько секунд для вызова Service.stopSelf() . При вызове Service.onTimeout() служба больше не считается службой переднего плана. Если служба не вызывает Service.stopSelf() , система выдает внутреннее исключение. Исключение регистрируется в Logcat со следующим сообщением:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"

Примечание. Ограничение по времени в 6 часов является общим для всех служб синхронизации dataSync приложения. Например, если приложение запускает службу dataSync в течение четырех часов, а затем запускает другую службу dataSync , второй службе будет разрешено работать только в течение двух часов. Однако если пользователь выводит приложение на передний план, таймер сбрасывается, и приложению становится доступно 6 часов.

Чтобы избежать проблем с этим изменением поведения, вы можете выполнить одно или несколько из следующих действий:

1. Пусть ваш сервис реализует новый метод Service.onTimeout(int, int) . Когда ваше приложение получит обратный вызов, обязательно вызовите stopSelf() в течение нескольких секунд. (Если вы не остановите приложение сразу, система выдаст ошибку.)
2. Убедитесь, что службы dataSync вашего приложения не работают более 6 часов в течение 24-часового периода (если только пользователь не взаимодействует с приложением, сбрасывая таймер).
3. Запускайте службы dataSync переднего плана только в результате прямого взаимодействия с пользователем; поскольку ваше приложение находится на переднем плане при запуске службы, у вашей службы есть полные шесть часов после того, как приложение перейдет в фоновый режим.
4. Вместо использования службы переднего плана dataSync используйте альтернативный API .

Если службы приоритетного плана dataSync вашего приложения работали в течение 6 часов за последние 24 часа, вы не сможете запустить другую службу приоритетного плана dataSync , пока пользователь не переведет ваше приложение на передний план (что сбрасывает таймер). Если вы попытаетесь запустить другую службу переднего плана dataSync , система выдаст исключение ForegroundServiceStartNotAllowedException с сообщением об ошибке, например «Ограничение времени для типа службы переднего плана dataSync уже исчерпано».

Тестирование

Чтобы проверить поведение вашего приложения, вы можете включить таймауты синхронизации данных, даже если ваше приложение не предназначено для Android 15 (при условии, что приложение работает на устройстве Android 15). Чтобы включить таймауты, выполните следующую команду adb :

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

Вы также можете настроить период ожидания, чтобы было проще протестировать поведение вашего приложения при достижении предела. Чтобы установить новый период ожидания, выполните следующую команду adb :

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

Новый тип приоритетной службы обработки мультимедиа

В Android 15 представлен новый тип службы переднего плана — mediaProcessing . Этот тип службы подходит для таких операций, как перекодирование медиафайлов. Например, мультимедийное приложение может загрузить аудиофайл, и ему необходимо преобразовать его в другой формат перед воспроизведением. Вы можете использовать службу переднего плана mediaProcessing чтобы гарантировать, что преобразование продолжается, даже когда приложение находится в фоновом режиме.

Система разрешает службам mediaProcessing приложения работать в общей сложности 6 часов в течение 24-часового периода, после чего система вызывает метод Service.onTimeout(int, int) работающей службы (представленный в Android 15). В это время у службы есть несколько секунд для вызова Service.stopSelf() . Если служба не вызывает Service.stopSelf() , система выдает внутреннее исключение. Исключение регистрируется в Logcat со следующим сообщением:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"

Примечание. Ограничение в 6 часов используется всеми службами переднего плана mediaProcessing приложения. Например, если приложение запускает службу mediaProcessing в течение четырех часов, а затем запускает другую службу mediaProcessing , второй службе будет разрешено работать только в течение двух часов. Однако если пользователь выводит приложение на передний план, таймер сбрасывается, и приложению становится доступно 6 часов.

Чтобы избежать исключения, вы можете сделать одно из следующих действий:

1. Пусть ваш сервис реализует новый метод Service.onTimeout(int, int) . Когда ваше приложение получит обратный вызов, обязательно вызовите stopSelf() в течение нескольких секунд. (Если вы не остановите приложение сразу, система выдаст ошибку.)
2. Убедитесь, что службы mediaProcessing вашего приложения не работают более 6 часов в течение любого 24-часового периода (если только пользователь не взаимодействует с приложением, сбрасывая таймер).
3. Запускайте службы переднего плана mediaProcessing только в результате прямого взаимодействия с пользователем; поскольку ваше приложение находится на переднем плане при запуске службы, у вашей службы есть полные шесть часов после того, как приложение перейдет в фоновый режим.
4. Вместо использования службы переднего плана mediaProcessing используйте альтернативный API , например WorkManager.

Если службы переднего плана mediaProcessing вашего приложения работали в течение 6 часов за последние 24, вы не сможете запустить другую службу переднего плана mediaProcessing , пока пользователь не переведет ваше приложение на передний план (что сбрасывает таймер). Если вы попытаетесь запустить другую службу переднего плана mediaProcessing , система выдаст ForegroundServiceStartNotAllowedException с сообщением об ошибке, например «Ограничение времени уже исчерпано для типа службы переднего плана mediaProcessing».

Дополнительные сведения о типе службы mediaProcessing см. в разделе Изменения в типах служб переднего плана для Android 15: обработка мультимедиа .

Тестирование

Чтобы проверить поведение вашего приложения, вы можете включить тайм-ауты обработки мультимедиа, даже если ваше приложение не предназначено для Android 15 (при условии, что приложение работает на устройстве Android 15). Чтобы включить таймауты, выполните следующую команду adb :

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

Вы также можете настроить период ожидания, чтобы было проще протестировать поведение вашего приложения при достижении предела. Чтобы установить новый период ожидания, выполните следующую команду adb :

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

Ограничения на широковещательные приемники BOOT_COMPLETED , запускающие службы приоритета

Существуют новые ограничения на широковещательные приемники BOOT_COMPLETED , запускающие службы приоритета. Получателям BOOT_COMPLETED не разрешено запускать следующие типы служб приоритета:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (это ограничение действует для microphone начиная с Android 14)

Если получатель BOOT_COMPLETED пытается запустить любой из этих типов служб переднего плана, система выдает исключение ForegroundServiceStartNotAllowedException .

Тестирование

Чтобы проверить поведение вашего приложения, вы можете включить эти новые ограничения, даже если ваше приложение не предназначено для Android 15 (при условии, что приложение работает на устройстве Android 15). Запустите следующую команду adb :

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

Чтобы отправить широковещательную рассылку BOOT_COMPLETED без перезагрузки устройства, выполните следующую команду adb :

adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name

Ограничения на запуск служб переднего плана, пока приложение имеет разрешение SYSTEM_ALERT_WINDOW

Раньше, если приложение имело разрешение SYSTEM_ALERT_WINDOW , оно могло запустить службу переднего плана, даже если приложение в данный момент находилось в фоновом режиме (как обсуждалось в разделе об исключениях из ограничений фонового запуска ).

Если приложение предназначено для Android 15, это исключение теперь уже. Теперь приложению необходимо иметь разрешение SYSTEM_ALERT_WINDOW , а также иметь видимое окно наложения. То есть приложению необходимо сначала запустить окно TYPE_APPLICATION_OVERLAY , и это окно должно быть видимым перед запуском службы переднего плана.

Если ваше приложение пытается запустить службу переднего плана в фоновом режиме, не отвечая этим новым требованиям (и у него нет других исключений), система выдает ForegroundServiceStartNotAllowedException .

Если ваше приложение объявляет разрешение SYSTEM_ALERT_WINDOW и запускает службы переднего плана в фоновом режиме, это изменение может повлиять на него. Если ваше приложение получает исключение ForegroundServiceStartNotAllowedException , проверьте порядок операций вашего приложения и убедитесь, что в нем уже есть активное окно наложения, прежде чем оно попытается запустить службу переднего плана из фона. Вы можете проверить, видимо ли ваше окно наложения в данный момент, вызвав View.getWindowVisibility() , или вы можете переопределить View.onWindowVisibilityChanged() чтобы получать уведомления при каждом изменении видимости.

Тестирование

Чтобы проверить поведение вашего приложения, вы можете включить эти новые ограничения, даже если ваше приложение не предназначено для Android 15 (при условии, что приложение работает на устройстве Android 15). Чтобы включить эти новые ограничения на запуск служб переднего плана в фоновом режиме, выполните следующую команду adb :

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

Изменения в условиях, когда приложения могут изменять глобальное состояние режима «Не беспокоить».

以 Android 15（API 级别 35）及更高版本为目标平台的应用无法再更改设备上的勿扰 (DND) 功能的全局状态或政策（无论是通过修改用户设置还是关闭勿扰模式）。相反，应用必须提供 AutomaticZenRule，系统会将其与现有的“最严格的政策优先”方案合并为一个全局政策。对之前会影响全局状态的现有 API 的调用（setInterruptionFilter、setNotificationPolicy）会导致创建或更新隐式 AutomaticZenRule，该 AutomaticZenRule 会根据这些 API 调用的调用周期开启和关闭。

请注意，只有当应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL) 并希望该调用停用之前由其所有者激活的 AutomaticZenRule 时，此更改才会影响可观察到的行为。

Изменения в API OpenJDK

Android 15 将继续更新 Android 的核心库，以与最新 OpenJDK LTS 版本中的功能保持一致。

以下变更可能会影响以 Android 15（API 级别 35）为目标平台的应用的兼容性：

• 对字符串格式化 API 进行了更改：现在，当使用以下 String.format() 和 Formatter.format() API 时，对参数索引、标志、 宽度和精度的验证要求变得更加严格：

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  例如，当使用实参索引 0（格式字符串中的 %0）时，系统会抛出以下异常：

  IllegalFormatArgumentIndexException: Illegal format argument index = 0
  

  在这种情况下，可以使用实参索引 1（格式字符串中的 %1）来解决此问题。

• 对 Arrays.asList(...).toArray() 的组件类型进行了更改：使用 Arrays.asList(...).toArray()时，生成的数组的组件类型现在是 Object，而不是底层数组元素的类型。因此，以下代码会抛出 ClassCastException：

  String[] elements = (String[]) Arrays.asList("one", "two").toArray();
  

  在这种情况下，如需在生成的 数组中保留 String 作为组件类型，您可以改用 Collection.toArray(Object[])：

  String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
  

• 对语言代码处理进行了更改：使用 Locale API 时， 希伯来语、意第绪语和印度尼西亚语的语言代码不再转换为 其过时形式（希伯来语：iw，意第绪语：ji，印度尼西亚语：in）。 指定其中一种语言区域的语言代码时，请改用 ISO 639-1 中的代码 （希伯来语：he，意第绪语：yi，印度尼西亚语：id）。

• 对随机 int 序列进行了更改：根据 https://bugs.openjdk.org/browse/JDK-8301574 中所做的更改，以下 Random.ints() 方法现在返回的数字序列与 the Random.nextInt() 方法返回的数字序列不同：

  • Random.ints(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

  一般来说，此更改不应导致应用出现破坏性行为，但您的代码不应期望从 Random.ints() 方法生成的序列与 Random.nextInt() 匹配。

新的 SequencedCollection API 可能会影响应用的兼容性 在应用的 build 配置中 更新 以使用 Android 15（API 级别 35）后：compileSdk

• 与 MutableList.removeFirst() 和 MutableList.removeLast() 扩展函数在 kotlin-stdlib 中发生冲突

  Java 中的 List 类型映射到 Kotlin 中的 MutableList 类型。 由于 List.removeFirst() 和 List.removeLast() API 是在 Android 15（API 级别 35）中引入的，因此 Kotlin 编译器 会将函数调用（例如 list.removeFirst()）静态解析为 新的 List API，而不是 kotlin-stdlib 中的扩展函数。

  如果使用 compileSdk 设置为 35 且 minSdk 设置为 34 或更低版本重新编译应用，然后在 Android 14 及更低版本上运行该应用，则会抛出运行时错误：

  java.lang.NoSuchMethodError: No virtual method
  removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
  

  Android Gradle 插件中现有的 NewApi lint 选项可以捕获这些新的 API 用法。

  ./gradlew lint
  
  MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
        list.removeFirst()
  

  如需修复运行时异常和 lint 错误，可以将 removeFirst() 和 removeLast() 函数调用分别替换为 Kotlin 中的 removeAt(0) 和 removeAt(list.lastIndex)。如果您使用的是 Android Studio Ladybug | 2024.1.3 或更高版本，它还为这些错误提供了快速修复选项。

  如果 lint 选项已停用，请考虑移除 @SuppressLint("NewApi") 和 lintOptions { disable 'NewApi' }。

• 与 Java 中的其他方法发生冲突

  新的方法已添加到现有类型中，例如， List 和 Deque。这些新方法可能与其他接口和类中具有相同名称和实参类型的方法不兼容。如果方法签名冲突且不兼容，javac 编译器会输出 build 时错误。例如：

  错误示例 1：

  javac MyList.java
  
  MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List
    public void removeLast() {
                ^
    return type void is not compatible with Object
    where E is a type-variable:
      E extends Object declared in interface List
  

  错误示例 2：

  javac MyList.java
  
  MyList.java:7: error: types Deque<Object> and List<Object> are incompatible;
  public class MyList implements  List<Object>, Deque<Object> {
    both define reversed(), but with unrelated return types
  1 error
  

  错误示例 3：

  javac MyList.java
  
  MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible;
  public static class MyList implements List<Object>, MyInterface<Object> {
    class MyList inherits unrelated defaults for getFirst() from types List and MyInterface
    where E#1,E#2 are type-variables:
      E#1 extends Object declared in interface List
      E#2 extends Object declared in interface MyInterface
  1 error
  

  如需修复这些 build 错误，实现这些接口的类应使用兼容的返回值类型替换该方法。例如：

  @Override
  public Object getFirst() {
      return List.super.getFirst();
  }
  

Безопасность

В Android 15 внесены изменения, повышающие безопасность системы и помогающие защитить приложения и пользователей от вредоносных программ.

Ограниченные версии TLS

Android 15 限制了对 TLS 版本 1.0 和 1.1 的使用。这些版本之前已在 Android 中被弃用，但现在不允许面向 Android 15 的应用使用。

Запуск защищенной фоновой активности

Android 15 做出了一些变更，可防止恶意后台应用将其他应用置于前台、提升自身权限并滥用用户互动，从而保护用户免受恶意应用的侵害，并让用户更好地控制自己的设备。自 Android 10（API 级别 29）起，后台 activity 启动受到限制。

其他更改

• 将 PendingIntent 创建者更改为默认阻止后台活动启动。这有助于防止应用意外创建可能被恶意行为者滥用的 PendingIntent。
• 除非 PendingIntent 发送方允许，否则请勿将应用转至前台。此变更旨在防止恶意应用滥用在后台启动 activity 的功能。默认情况下，除非创建者允许后台 activity 启动权限或发送者具有后台 activity 启动权限，否则不允许应用将任务堆栈带到前台。
• 控制任务堆栈的顶层 activity 如何完成其任务。如果顶部 activity 完成了一项任务，Android 将返回到上次处于活跃状态的任务。此外，如果非顶部 activity 完成其任务，Android 会返回到主屏幕；它不会阻止此非顶部 activity 完成。
• 防止从其他应用启动任意 activity 进入您自己的任务。此变更可防止恶意应用通过创建看似来自其他应用的 activity 来对用户进行钓鱼式攻击。
• 阻止将非可见窗口纳入后台 activity 启动的考虑范围。这有助于防止恶意应用滥用后台活动启动来向用户显示不必要或恶意的内容。

Более безопасные намерения

Android 15 针对 intent 引入了 StrictMode。

如需查看有关 Intent 使用违规行为的详细日志，请使用以下方法：

Kotlin

fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

Java

public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

Пользовательский опыт и пользовательский интерфейс системы

В Android 15 внесены некоторые изменения, призванные обеспечить более согласованный и интуитивно понятный пользовательский интерфейс.

Изменения отступа окна

Есть два изменения, связанных с вставками окон в Android 15: по умолчанию применяется сквозное изображение, а также есть изменения конфигурации, такие как конфигурация системных панелей по умолчанию.

全面实施政策

Приложения по умолчанию отображаются без рамок на устройствах под управлением Android 15, если приложение ориентировано на Android 15 (уровень API 35).

Важно: если ваше приложение еще не оптимизировано под все края экрана, некоторые его части могут быть скрыты, и вам потребуется обработать отступы. В зависимости от приложения, эта работа может быть значительной или незначительной. Компонент Material 3 Scaffold может упростить работу по обеспечению совместимости с требованиями Android 15 к оптимизации под все края экрана.

Приложение, ориентированное на Android 14 и не поддерживающее безрамочное отображение на устройствах с Android 15.

Приложение, ориентированное на Android 15 (уровень API 35) и работающее в режиме «от края до края» на устройствах Android 15. В основном в этом приложении используются компоненты Material 3 Compose, которые автоматически применяют отступы. Применение режима «от края до края» в Android 15 не оказывает негативного влияния на этот экран.

Это критическое изменение, которое может негативно повлиять на пользовательский интерфейс вашего приложения. Изменения затрагивают следующие области пользовательского интерфейса:

• Панель навигации с помощью жестов
  • По умолчанию прозрачный.
  • Функция смещения вниз отключена, поэтому контент отображается за панелью навигации системы, если не применены отступы.
  • setNavigationBarColor и R.attr#navigationBarColor устарели и не влияют на навигацию жестами.
  • setNavigationBarContrastEnforced и R.attr#navigationBarContrastEnforced по-прежнему не влияют на навигацию жестами.
• 3-кнопочная навигация
  • По умолчанию непрозрачность установлена ​​на 80%, при этом цвет может соответствовать фону окна.
  • Отключено смещение снизу, поэтому контент отображается за панелью навигации системы, если не применены отступы.
  • setNavigationBarColor и R.attr#navigationBarColor по умолчанию устанавливают цвет в соответствии с фоном окна. Для применения этого значения по умолчанию фон окна должен быть задан цветом из графического объекта. Этот API устарел, но продолжает влиять на навигацию с тремя кнопками.
  • setNavigationBarContrastEnforced и R.attr#navigationBarContrastEnforced по умолчанию установлено значение true, что добавляет 80% непрозрачный фон к навигации из 3 кнопок.
• Строка состояния
  • По умолчанию прозрачный.
  • Верхнее смещение отключено, поэтому контент отображается за строкой состояния, если не применены отступы.
  • setStatusBarColor и R.attr#statusBarColor устарели и не оказывают никакого влияния на Android 15.
  • setStatusBarContrastEnforced и R.attr#statusBarContrastEnforced устарели, но по-прежнему эффективны на Android 15.
• Вырез для дисплея
  • Для неплавающих окон layoutInDisplayCutoutMode должен быть установлен LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS . SHORT_EDGES , NEVER и DEFAULT интерпретируются как ALWAYS , чтобы пользователи не видели черную полосу, вызванную вырезом в экране, и чтобы окно отображалось от края до края.

В следующем примере показано приложение до и после перехода на Android 15 (уровень API 35), а также до и после применения отступов. Этот пример не является исчерпывающим, в Android Auto это может выглядеть иначе.

Приложение, ориентированное на Android 14 и не поддерживающее безрамочное отображение на устройствах с Android 15.

Приложение, ориентированное на Android 15 (уровень API 35) и работающее в режиме «от края до края» на устройствах Android 15. Однако многие элементы теперь скрыты строкой состояния, панелью навигации с тремя кнопками или вырезом в экране из-за требований Android 15 к отображению «от края до края». К скрытым элементам интерфейса относятся верхняя панель приложения Material 2, плавающие кнопки действий и элементы списка.

Приложение, ориентированное на Android 15 (уровень API 35), имеет безрамочный дизайн на устройствах Android 15 и использует отступы, чтобы пользовательский интерфейс не скрывался.

Что проверить, если ваше приложение уже полностью занимает всю ширину экрана?

Если ваше приложение уже имеет полноэкранный режим и применяет отступы, то в большинстве случаев это вас не затронет, за исключением следующих сценариев. Однако, даже если вы считаете, что это вас не коснется, мы рекомендуем протестировать ваше приложение.

• У вас неплавающее окно, например, Activity , которое использует SHORT_EDGES , NEVER или DEFAULT вместо LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS . Если ваше приложение вылетает при запуске, это может быть связано с вашим заставочным экраном. Вы можете либо обновить основную зависимость заставочного экрана до 1.2.0-alpha01 или более поздней, либо установить window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always .
• Возможно, существуют экраны с низкой посещаемостью, на которых частично перекрыт пользовательский интерфейс. Убедитесь, что на этих менее посещаемых экранах нет перекрытого пользовательского интерфейса. К экранам с низкой посещаемостью относятся:
  • Экраны регистрации или входа в систему
  • Страницы настроек

Что проверить, если ваше приложение еще не оптимизировано для отображения всего экрана?

Если ваше приложение ещё не является полностью открытым (bread to edge), то, скорее всего, оно вас затронет. Помимо сценариев для приложений, которые уже являются полностью открытыми (bread to edge), следует учитывать следующее:

• Если ваше приложение использует компоненты Material 3 ( androidx.compose.material3 ) в Compose, такие как TopAppBar , BottomAppBar и NavigationBar , то эти компоненты, скорее всего, не будут затронуты, поскольку они автоматически обрабатывают отступы.
• Если ваше приложение использует компоненты Material 2 ( androidx.compose.material ) в Compose, эти компоненты не обрабатывают отступы автоматически. Однако вы можете получить доступ к отступам и применить их вручную. В androidx.compose.material версии 1.6.0 и выше используйте параметр windowInsets , чтобы вручную применить отступы для BottomAppBar , TopAppBar , BottomNavigation и NavigationRail . Аналогично используйте параметр contentWindowInsets для Scaffold .
• Если ваше приложение использует представления и компоненты Material ( com.google.android.material ), большинство компонентов Material на основе представлений, таких как BottomNavigationView , BottomAppBar , NavigationRailView или NavigationView , обрабатывают отступы и не требуют дополнительной работы. Однако вам необходимо добавить android:fitsSystemWindows="true" если вы используете AppBarLayout .
• Для пользовательских элементов, создаваемых с помощью компоновки, задайте отступы вручную. Если ваш контент находится внутри Scaffold , вы можете использовать значения отступов Scaffold . В противном случае задайте отступы с помощью одного из WindowInsets .
• Если ваше приложение использует представления и BottomSheet , SideSheet или пользовательские контейнеры, примените отступы с помощью ViewCompat.setOnApplyWindowInsetsListener . Для RecyclerView примените отступы с помощью этого слушателя, а также добавьте clipToPadding="false" .

Что проверить, если вашему приложению необходима настраиваемая защита от фоновых процессов?

Если вашему приложению необходимо обеспечить настраиваемую защиту фона для трехкнопочной навигации или строки состояния, то следует разместить компонент или представление за системной панелью, используя WindowInsets.Type#tappableElement() для получения высоты трехкнопочной панели навигации или WindowInsets.Type#statusBars .

Дополнительные ресурсы, охватывающие все аспекты.

Дополнительные сведения о применении отступов см. в руководствах « Вид от края до края» и «Композиция от края до края» .

Устаревшие API

Следующие API-интерфейсы устарели, но не отключены:

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor (для навигации с 3 кнопками, с 80% прозрачностью)
• Window#isStatusBarContrastEnforced
• Window#setNavigationBarColor (для навигации с 3 кнопками, с 80% прозрачностью)
• Window#setStatusBarContrastEnforced

Следующие API-интерфейсы устарели и отключены:

• R.attr#navigationBarColor (для навигации жестами)
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#setDecorFitsSystemWindows
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#setNavigationBarColor (для навигации жестами)
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor

稳定配置

Если ваше приложение ориентировано на Android 15 (уровень API 35) или выше, Configuration больше не исключает системные панели. Если вы используете размер экрана в классе Configuration для расчета компоновки, вам следует заменить его на более подходящие альтернативы, такие как соответствующий ViewGroup , WindowInsets или WindowMetricsCalculator в зависимости от ваших потребностей.

Configuration доступны с API 1. Обычно их получают из Activity.onConfigurationChanged . Они предоставляют информацию, такую ​​как плотность окон, ориентация и размеры. Важной особенностью размеров окон, возвращаемых Configuration является то, что ранее они не включали системные панели.

Размер конфигурации обычно используется для выбора ресурсов, например, /res/layout-h500dp , и это по-прежнему допустимый вариант использования. Однако использование его для расчета компоновки всегда не рекомендовалось. Если вы все же используете его, вам следует отказаться от него. Вам следует заменить использование Configuration чем-то более подходящим в зависимости от ваших задач.

Если вы используете его для расчета компоновки, используйте соответствующий ViewGroup , например CoordinatorLayout или ConstraintLayout . Если вы используете его для определения высоты системной панели навигации, используйте WindowInsets . Если вы хотите узнать текущий размер окна вашего приложения, используйте computeCurrentWindowMetrics .

Ниже приведён список полей, затронутых этим изменением:

• Размеры Configuration.screenWidthDp и screenHeightDp больше не исключают системные полосы.
• Изменения параметров screenWidthDp и screenHeightDp косвенно влияют на Configuration.smallestScreenWidthDp .
• На устройствах с почти квадратным экраном изменения параметров screenWidthDp и screenHeightDp косвенно влияют на Configuration.orientation .
• Display.getSize(Point) косвенно зависит от изменений в Configuration . Он был объявлен устаревшим начиная с уровня API 30.
• Display.getMetrics() работает подобным образом уже с 33-го уровня API.

Атрибут elegantTextHeight по умолчанию имеет значение true.

Для приложений, ориентированных на Android 15 (уровень API 35), атрибут elegantTextHeight TextView становится true по умолчанию, заменяя компактный шрифт, используемый по умолчанию, некоторыми скриптами с большими вертикальными метриками на гораздо более читаемый. Компактный шрифт был введен, чтобы предотвратить нарушение макета; Android 13 (уровень API 33) предотвращает многие из этих проблем, позволяя текстовому макету растягивать вертикальную высоту с помощью атрибута fallbackLineSpacing .

В Android 15 компактный шрифт по-прежнему остается в системе, поэтому ваше приложение может установить для elegantTextHeight значение false чтобы получить то же поведение, что и раньше, но вряд ли он будет поддерживаться в следующих выпусках. Итак, если ваше приложение поддерживает следующие сценарии: арабский, лаосский, мьянманский, тамильский, гуджаратский, каннада, малаялам, одиа, телугу или тайский, протестируйте свое приложение, установив для elegantTextHeight значение true .

Поведение elegantTextHeight для приложений, ориентированных на Android 14 (уровень API 34) и ниже.

Поведение elegantTextHeight для приложений, ориентированных на Android 15.

Изменение ширины TextView для сложных форм букв

在以前的 Android 版本中，某些具有复杂形状的手写字体或语言可能会在上一个或下一个字符的区域绘制字母。在某些情况下，此类字母会在开头或结尾处被剪裁。从 Android 15 开始，TextView 会分配宽度，以便为此类字母绘制足够的空间，并允许应用请求向左额外添加内边距以防止剪裁。

由于此更改会影响 TextView 确定宽度的方式，因此如果应用以 Android 15（API 级别 35）或更高版本为目标平台，TextView 会默认分配更多宽度。您可以通过对 TextView 调用 setUseBoundsForWidth API 来启用或停用此行为。

由于添加左内边距可能会导致现有布局未对齐，因此默认情况下不会添加内边距，即使以 Android 15 或更高版本为目标平台的应用也是如此。不过，您可以通过调用 setShiftDrawingOffsetForStartOverhang 添加额外的内边距以防止剪裁。

以下示例展示了这些更改如何改进某些字体和语言的文本布局。

采用手写体字体的英语文本的标准布局。部分字母被截断。对应的 XML 如下：

<TextView
    android:fontFamily="cursive"
    android:text="java" />

相同英语文本的布局，增加了宽度和内边距。以下是相应的 XML：

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

泰语文本的标准布局。部分字母被截断。 以下是相应的 XML：

<TextView
    android:text="คอมพิวเตอร์" />

相同泰语文本的布局，增加了宽度和内边距。以下是相应的 XML：

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Высота строки по умолчанию для EditText с учетом локали

在较低版本的 Android 中，文本布局会拉伸文本的高度，以满足与当前语言区域匹配的字体的行高。例如，如果内容是日语，由于日语字体的行高略高于拉丁字体，因此文本的高度会略高。不过，尽管行高存在这些差异，但无论使用的是哪种语言区域，EditText 元素的大小都是统一的，如下图所示：

三个框，表示可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 文本的 EditText 元素。EditText 的高度相同，即使这些语言的行高各不相同。

对于以 Android 15（API 级别 35）为目标平台的应用，现在为 EditText 预留了最小行高，以匹配指定语言区域的参考字体，如下图所示：

三个框，表示可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 文本的 EditText 元素。EditText 的高度现在包含足够的空间来容纳这些语言字体的默认行高。

如有需要，您的应用可以将 useLocalePreferredLineHeightForMinimum 属性指定为 false，以恢复之前的行为；您的应用还可以在 Kotlin 和 Java 中使用 setMinimumFontMetrics API 设置自定义最小垂直指标。

Камера и медиа

В Android 15 внесены следующие изменения в работу камеры и мультимедиа для приложений, ориентированных на Android 15 и выше.

Ограничения на запрос фокусировки звука

Приложения, предназначенные для Android 15 (уровень API 35), должны быть главным приложением или запускать службу переднего плана, чтобы запросить фокус звука . Если приложение пытается запросить фокус, хотя оно не соответствует одному из этих требований, вызов возвращает AUDIOFOCUS_REQUEST_FAILED .

Дополнительную информацию о фокусе звука можно узнать в разделе «Управление фокусом звука» .

Обновлены ограничения, не относящиеся к SDK.

В Android 15 обновлены списки ограниченных интерфейсов, не использующих SDK, на основе сотрудничества с разработчиками Android и последних внутренних тестов. По возможности мы обеспечиваем наличие общедоступных альтернатив, прежде чем ограничивать использование интерфейсов, не использующих SDK.

Если ваше приложение не ориентировано на Android 15, некоторые из этих изменений могут не сразу повлиять на него. Однако, хотя ваше приложение может получить доступ к некоторым интерфейсам, не связанным с SDK, в зависимости от целевого уровня API вашего приложения , использование любого метода или поля, не связанного с SDK, всегда сопряжено с высоким риском нарушения работы вашего приложения.

Если вы не уверены, использует ли ваше приложение интерфейсы, отличные от SDK, вы можете протестировать его , чтобы это выяснить. Если ваше приложение зависит от интерфейсов, отличных от SDK, вам следует начать планировать переход на альтернативы SDK. Тем не менее, мы понимаем, что в некоторых приложениях есть обоснованные сценарии использования интерфейсов, отличных от SDK. Если вы не можете найти альтернативу использованию интерфейса, отличного от SDK, для какой-либо функции в вашем приложении, вам следует запросить новый публичный API .

Дополнительные сведения об изменениях в этой версии Android см. в разделе Обновления ограничений интерфейса, не связанных с SDK, в Android 15 . Дополнительные сведения об интерфейсах, отличных от SDK, см. в разделе Ограничения на интерфейсы, не относящиеся к SDK .