Эта страница переведена с помощью Cloud Translation API.

Изменения в поведении Android 5.0

Уровень API: 21

Помимо новых функций и возможностей, Android 5.0 включает в себя множество системных изменений и изменений поведения API. В этом документе освещаются некоторые ключевые изменения, которые вы должны понимать и учитывать в своих приложениях.

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

Более общий обзор новых функций платформы можно найти в обзоре Android Lollipop .

Видео

Dev Byte: что нового в Android 5.0

Байт разработчика: уведомления

Среда выполнения Android (ART)

В Android 5.0 среда выполнения ART заменяет Dalvik в качестве платформы по умолчанию. Среда выполнения ART была представлена в Android 4.4 на экспериментальной основе.

Обзор новых функций ART см. в разделе Знакомство с ART . Некоторые из основных новых функций:

Предварительная компиляция (AOT)
Улучшенная сборка мусора (GC).
Улучшенная поддержка отладки

Большинство приложений Android должны работать без каких-либо изменений в ART. Однако некоторые методы, работающие на Dalvik, не работают на ART. Информацию о наиболее важных проблемах см. в разделе Проверка поведения приложений в среде выполнения Android (ART) . Обратите особое внимание, если:

Ваше приложение использует собственный интерфейс Java (JNI) для запуска кода C/C++.
Вы используете инструменты разработки, которые генерируют нестандартный код (например, некоторые обфускаторы).
Вы используете методы, несовместимые с уплотнением сборки мусора.

Уведомления

Убедитесь, что ваши уведомления учитывают эти изменения Android 5.0. Дополнительную информацию о разработке уведомлений для Android 5.0 и более поздних версий см. в руководстве по созданию уведомлений .

Материальный стиль дизайна

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

Используйте setColor() чтобы установить цвет акцента в круге позади изображения значка.
Обновите или удалите ресурсы, содержащие цвет. Система игнорирует все не-альфа-каналы в значках действий и в главном значке уведомлений. Вы должны предположить, что эти значки будут только альфа-версиями. Система рисует значки уведомлений белым цветом, а значки действий — темно-серым.

Звук и вибрация

Если вы в настоящее время добавляете звуки и вибрацию к своим уведомлениям с помощью классов Ringtone , MediaPlayer или Vibrator , удалите этот код, чтобы система могла правильно отображать уведомления в приоритетном режиме. Вместо этого используйте методы Notification.Builder для добавления звуков и вибрации.

Установка для устройства значения RINGER_MODE_SILENT приводит к тому, что устройство переходит в новый режим приоритета. Устройство выходит из режима приоритета, если вы установите для него значение RINGER_MODE_NORMAL или RINGER_MODE_VIBRATE .

Раньше Android использовал STREAM_MUSIC в качестве основного потока для управления громкостью на планшетных устройствах. В Android 5.0 основной поток громкости для телефонов и планшетов теперь унифицирован и управляется STREAM_RING или STREAM_NOTIFICATION .

Видимость экрана блокировки

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

Если уведомление не содержит личной информации или вы хотите разрешить управление воспроизведением мультимедиа в уведомлении, вызовите метод setVisibility() и установите уровень видимости уведомления на VISIBILITY_PUBLIC .

Воспроизведение мультимедиа

Если вы реализуете уведомления, которые отображают состояние воспроизведения мультимедиа или элементы управления транспортировкой, рассмотрите возможность использования нового шаблона Notification.MediaStyle вместо пользовательского объекта RemoteViews.RemoteView . Какой бы подход вы ни выбрали, обязательно установите для видимости уведомления значение VISIBILITY_PUBLIC , чтобы ваши элементы управления были доступны с экрана блокировки. Обратите внимание, что начиная с Android 5.0 система больше не отображает объекты RemoteControlClient на экране блокировки. Дополнительные сведения см. в разделе «Если ваше приложение использует RemoteControlClient» .

Предварительное уведомление

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

Примеры условий, которые могут вызвать хедз-ап уведомления:

Действия пользователя происходят в полноэкранном режиме (приложение использует fullScreenIntent ).
Уведомление имеет высокий приоритет и использует мелодии звонка или вибрацию.

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

Элементы управления мультимедиа и RemoteControlClient

Класс RemoteControlClient устарел. Перейдите на новый API MediaSession как можно скорее.

На экранах блокировки в Android 5.0 не отображаются элементы управления транспортировкой для вашего MediaSession или RemoteControlClient . Вместо этого ваше приложение может обеспечить управление воспроизведением мультимедиа с экрана блокировки посредством уведомления. Это дает вашему приложению больше контроля над представлением мультимедийных кнопок, обеспечивая при этом единообразную работу пользователей на заблокированных и разблокированных устройствах.

Для этой цели в Android 5.0 представлен новый шаблон Notification.MediaStyle . Notification.MediaStyle преобразует действия уведомлений, добавленные с помощью Notification.Builder.addAction() , в компактные кнопки, встроенные в уведомления о воспроизведении мультимедиа вашего приложения. Передайте токен сеанса методу setSession() , чтобы сообщить системе, что это уведомление контролирует текущий сеанс мультимедиа.

Обязательно установите для видимости уведомления значение VISIBILITY_PUBLIC , чтобы пометить уведомление как безопасное для отображения на любом экране блокировки (безопасном или ином). Дополнительную информацию см. в разделе Уведомления на экране блокировки .

Чтобы отобразить элементы управления воспроизведением мультимедиа, если ваше приложение работает на платформе Android TV или Wear , реализуйте класс MediaSession . Вам также следует реализовать MediaSession , если вашему приложению необходимо получать события мультимедийных кнопок на устройствах Android.

getRecentTasks()

С появлением новой функции задач по одновременным документам и действиям в Android 5.0 (см. раздел «Одновременные документы и действия» на экране «Последние» ниже) метод ActivityManager.getRecentTasks() стал устаревшим в целях повышения конфиденциальности пользователей. В целях обратной совместимости этот метод по-прежнему возвращает небольшое подмножество своих данных, включая собственные задачи вызывающего приложения и, возможно, некоторые другие неконфиденциальные задачи (например, Home). Если ваше приложение использует этот метод для получения своих собственных задач, вместо этого используйте getAppTasks() для получения этой информации.

Поддержка 64-битной версии в Android NDK

В Android 5.0 появилась поддержка 64-битных систем. 64-битное улучшение увеличивает адресное пространство и повышает производительность, сохраняя при этом полную поддержку существующих 32-битных приложений. Поддержка 64-бит также повышает производительность OpenSSL для криптографии. Кроме того, в этом выпуске представлены новые API-интерфейсы NDK для мультимедиа, а также встроенная поддержка OpenGL ES (GLES) 3.1.

Чтобы использовать поддержку 64-разрядных систем, предусмотренную в Android 5.0, загрузите и установите NDK Revision 10c со страницы Android NDK . Дополнительную информацию о важных изменениях и исправлениях ошибок в NDK см. в примечаниях к выпуску версии 10c.

Привязка к службе

Метод Context.bindService() теперь требует явного Intent и выдает исключение, если задано неявное намерение. Чтобы обеспечить безопасность вашего приложения, используйте явное намерение при запуске или привязке Service и не объявляйте фильтры намерений для службы.

Веб-представление

Android 5.0 меняет поведение вашего приложения по умолчанию.

Если ваше приложение ориентировано на уровень API 21 или выше:
- По умолчанию система блокирует смешанный контент и сторонние файлы cookie. Чтобы разрешить смешанный контент и сторонние файлы cookie, используйте методы setMixedContentMode() и setAcceptThirdPartyCookies() соответственно.
- Теперь система разумно выбирает части HTML-документа для рисования. Это новое поведение по умолчанию помогает уменьшить объем памяти и повысить производительность. Если вы хотите визуализировать весь документ сразу, отключите эту оптимизацию, вызвав enableSlowWholeDocumentDraw() .
Если ваше приложение нацелено на уровни API ниже 21: система допускает смешанный контент и сторонние файлы cookie и всегда отображает весь документ одновременно.

Требование уникальности для пользовательских разрешений

Как указано в обзоре разрешений , приложения Android могут определять настраиваемые разрешения как средство управления доступом к компонентам собственным способом без использования заранее определенных системных разрешений платформы. Приложения определяют пользовательские разрешения в элементах <permission> , объявленных в их файлах манифеста.

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

Android 5.0 включает изменение поведения, гарантирующее, что только одно приложение может определить данное пользовательское разрешение, если только оно не подписано тем же ключом, что и другие приложения, определяющие разрешение.

Приложения, использующие повторяющиеся пользовательские разрешения

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

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

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

Новые установки и обновления

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

Существующие установки с обновлением системы Android 5.0

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

Изменения конфигурации TLS/SSL по умолчанию

В Android 5.0 внесены изменения в конфигурацию TLS/SSL по умолчанию, используемую приложениями для HTTPS и другого трафика TLS/SSL:

Протоколы TLSv1.2 и TLSv1.1 теперь включены,
Наборы шифров AES-GCM (AEAD) теперь включены,
Наборы шифров MD5, 3DES, экспорта и статического ключа ECDH теперь отключены.
Предпочтительны наборы шифров прямой секретности (ECDHE и DHE).

Эти изменения могут привести к сбоям в подключении HTTPS или TLS/SSL в небольшом количестве случаев, перечисленных ниже.

Обратите внимание, что ProviderInstaller безопасности из сервисов Google Play уже предлагает эти изменения для всех версий платформы Android, начиная с Android 2.3.

Сервер не поддерживает ни один из включенных наборов шифров.

Например, сервер может поддерживать только наборы шифров 3DES или MD5. Предпочтительным решением является улучшение конфигурации сервера для включения более надежных и современных наборов шифров и протоколов. В идеале должны быть включены TLSv1.2 и AES-GCM, а наборы шифров прямой секретности (ECDHE, DHE) должны быть включены и предпочтительны.

Альтернативой является изменение приложения для использования пользовательского SSLSocketFactory для связи с сервером. Фабрика должна быть спроектирована так, чтобы создавать экземпляры SSLSocket, в которых включены некоторые наборы шифров, необходимые серверу, в дополнение к наборам шифров по умолчанию.

Приложение делает неверные предположения о наборах шифров, используемых для подключения к серверу

Например, некоторые приложения содержат пользовательский X509TrustManager, который дает сбой, поскольку ожидает, что параметр authType будет RSA, но обнаруживает ECDHE_RSA или DHE_RSA.

Сервер нетерпим к TLSv1.1, TLSv1.2 или новым расширениям TLS.

Например, подтверждение TLS/SSL с сервером ошибочно отклонено или зависает. Предпочтительным решением является обновление сервера для обеспечения соответствия протоколу TLS/SSL. Это позволит серверу успешно согласовать эти новые протоколы или согласовать TLSv1 или более старые протоколы и игнорировать расширения TLS, которые он не понимает. В некоторых случаях отключение TLSv1.1 и TLSv1.2 на сервере может служить временной мерой до тех пор, пока программное обеспечение сервера не будет обновлено.

Альтернативой является изменение приложения для использования пользовательского SSLSocketFactory для связи с сервером. Фабрика должна быть спроектирована так, чтобы создавать экземпляры SSLSocket только с включенными протоколами, которые правильно поддерживаются сервером.

Поддержка управляемых профилей

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

Обработка намерений

Администраторы устройств могут ограничить доступ к системным приложениям из управляемого профиля. В этом случае, если приложение запускает намерение из управляемого профиля, которое обычно обрабатывается этим приложением, и нет подходящего обработчика для намерения в управляемом профиле, намерение вызывает исключение. Например, администратор устройства может ограничить приложениям управляемого профиля доступ к системному приложению камеры. Если ваше приложение работает в управляемом профиле и вызывает startActivityForResult() для MediaStore.ACTION_IMAGE_CAPTURE , а в управляемом профиле нет приложения, которое могло бы обработать это намерение, это приводит к исключению ActivityNotFoundException .

Вы можете предотвратить это, проверив наличие хотя бы одного обработчика для любого намерения перед его запуском. Чтобы проверить допустимый обработчик, вызовите Intent.resolveActivity() . Вы можете увидеть пример того, как это делается, в разделе «Сделайте фотографии просто: сделайте снимок с помощью приложения камеры» .

Обмен файлами между профилями

Каждый профиль имеет собственное хранилище файлов. Поскольку URI файла относится к определенному местоположению в хранилище файлов, это означает, что URI файла, действительный для одного профиля, недействителен для другого. Обычно это не проблема для приложения, которое обычно просто обращается к созданным им файлам. Однако если приложение прикрепляет файл к намерению, прикреплять URI файла небезопасно, поскольку в некоторых случаях намерение может обрабатываться в другом профиле. Например, администратор устройства может указать, что события захвата изображения должны обрабатываться приложением камеры в личном профиле. Если намерение активируется приложением в управляемом профиле, камера должна иметь возможность записывать изображение в место, где приложения управляемого профиля смогут его прочитать.

В целях безопасности, когда вам нужно прикрепить файл к намерению, которое может переходить из одного профиля в другой, вам следует создать и использовать URI контента для файла. Дополнительные сведения о совместном использовании файлов с помощью URI контента см. в разделе Общий доступ к файлам . Например, администратор устройства может разрешить камере в личном профиле обрабатывать ACTION_IMAGE_CAPTURE . EXTRA_OUTPUT намерения активации должен содержать URI контента, указывающий, где должна храниться фотография. Приложение камеры может записать изображение в местоположение, указанное этим URI, и приложение, инициировавшее намерение, сможет прочитать этот файл, даже если приложение находится в другом профиле.

В Android 5.0 удалена поддержка виджетов экрана блокировки; он продолжает поддерживать виджеты на главном экране.