nekdenis Nov 3 2015 at 10:43

Android 6.0: Doze Mode, App Standby, Runtime Permissions. Всё, что необходимо знать каждому разработчику

5 min

65K

Development of mobile applications*Development for Android*Mobile applications testing*

+25

Comments 17

AllexIn Nov 3 2015 at 11:43

А что будет со старыми приложениям, у которых опасные permissions прописаны в манифесте?

nekdenis Nov 3 2015 at 11:49

Если у них targetSdk 22 или ниже, то все будет хорошо, пермишены они получат автоматом.
Но пользователь может зайти в настройки, и запретить приложению доступ к любому из сервисов, например, к камере. Его система предупредит:«Не надо так, приложение не оптимизировано, может упасть!».
Но он все равно может запретитить. В этом случае SecurityException не вывалится, а будут следующие сценарии, для локейшн и камеры, к примеру, будут возвращены null, для контактов — пустой список или пустой контакт.

oWeRQ Nov 3 2015 at 15:40

Тогда какой стимул будет для «плохих» приложений обновлять sdk на > 22?

petrovichtim Nov 3 2015 at 15:52

Как бы более низкая выдача в поиске.

samodum Nov 4 2015 at 05:36

Как бы это не самое страшное для «плохих» приложений

nekdenis Nov 3 2015 at 17:28

фишки нового api не задействовать, саппорты новые не запустить, плей сервисы — много всего

thevery Nov 3 2015 at 22:41

А что с саппортами не так? И разве android будет принудительно «портить» фичи при старом targetSdk?

AllexIn Nov 3 2015 at 21:33

Нет смысла оставаться на старом SDK. Всё равно ОС не даст разрешения или пользователь их отрубит, а отреагировать на старом SDK не получится корректно.

thevery Nov 3 2015 at 22:44

Имхо шансы на отключение пермишшенов в настройках во много раз ниже, чем на запрет прямо при запросе приложения.

dumistoklus Nov 3 2015 at 14:12

А еще важное замечание: нормальные разрешения пользователь не может отозвать, если они уже были даны при установке приложения

AllexIn Nov 4 2015 at 10:08

Ну это логично, ведь они в манифесте. И если приложение запустилось, предполагается, что разрешения все уже даны и ничего проверять не нужно.
Опять же, отозвать можно — через удаление приложения.

VioletGiraffe Nov 6 2015 at 09:45

Doze Mode может серьёзно поломать моё приложение, предвижу жалобы от пользователей. Моя софтина коннектится к цифровой камере и управляет ею по проводу или Wi-Fi. Вот как, например, снимать time lapse, который может длиться много часов, если через час девайс заснёт, невзирая на мой wake lock?

andrey7mel Nov 6 2015 at 12:14

При старте просить добавить свое приложение в Whitelist (… Приложениям из Whitelist не страшны ни Doze Mode ни App Standby).

VioletGiraffe Nov 6 2015 at 12:19

Спасибо!

b1rdex Nov 10 2015 at 06:36

А если у нас приложение будильник, то мы должны обязательно вызвать для Alarm setAndAllowWhileIdle() или setExactAndAllowWhileIdle().

Хоть автор и заблуждается насчёт будильника, эти методы действительно разбудят телефон (AlarmManager API23+).

А для будильника нужно продолжать использовать setAlarmClock().

coder1cv8 Nov 6 2015 at 12:46

Вот еще хорошая заметка о новом механизме Permissions: code.tutsplus.com/articles/understanding-permissions-in-android-m--cms-24443 (eng). Вот прямо сегодня добавлял в одно из своих приложений, все просто и понятно.

comhot Nov 10 2015 at 11:25

Описать только PROTECTION_NORMAL запросы в manifest

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