App permissions что это такое на планшете

App permissions что это такое на планшете

App Permissions в Android – что это и как его использовать

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

Зачем необходим App Permissions на Android и как его удалить.

Что это такое

App Permissions – это и есть разрешения. Когда вы устанавливаете софт из Google Play на устройстве под управлением Android 6.0 или выше, вы контролируете, к каким возможностям или информации может обращаться программа – так называемые разрешения. Например, утилите может потребоваться разрешение на просмотр контактов или местоположения вашего устройства. Вы можете контролировать, к каким разрешениям ПО сможет получить доступ после установки на устройстве. И если «Автоматический запуск программы при загрузке» говорит само за себя, то разобраться в остальных может быть не так просто. Проблема в том, что программы могут иметь веские основания для их использования, потому что одним разрешением может быть охвачено несколько разных вещей. Рассмотрим самые распространённые примеры менеджмента разрешений более подробно.

Совершать и принимать вызовы

Это означает, что ПО может автоматически сделать звонок. Каждая утилита может самостоятельно запускать номеронабиратель и даже вводить номер, но, если это разрешение не предоставлено, пользователю нужно нажать кнопку вызова. Такие вещи, как сторонний номеронабиратель, Google Voice или всё, что связано с вашей телефонной «звонилкой», должно иметь это разрешение. Если ПО его запрашивает, но не должно иметь ничего общего с совершением звонков, отклоните запрос и выясните причину запроса у разработчиков через отзывы на Google Play. Даже если причины использования того или иного разрешения вам не понятны, они могут требоваться для стабильной работы программ.

Получение и отправка SMS или MMS

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

Чтение/запись контактов

Почтовый клиент или мессенджер любого типа использует это разрешение, чтобы делать именно то, о чём говорит его название – читать ваши контакты. Например, Twitter или Facebook – они хотят иметь возможность находить ваших друзей, которые также пользуются их услугами, или упростить для вас рассылку спама тем, кто этого не делает. «Контакты» – это широкий термин, потому что в отдельном контакте может храниться много различной информации. Например, в играх, где также есть списки лидеров. Всё, что может связать вас с другим пользователем, будет нуждаться в этом разрешении. Права на сохранение контактов следует той же логике – если утилита может добавить контакт, ей может потребоваться это разрешение. В этом случае «записать» означает изменить или добавить в список контактов, а не написать сообщение.

Чтение/запись событий календаря

Здесь всё довольно просто. Настройка позволяет делать только одно – автоматически читать календарь. Некоторые утилиты должны иметь доступ к календарю. Это программы, которые могут напоминать о приёме лекарств или автоматически сообщать о предстоящей поездке, считывая данные из календаря. Если программа каким-либо образом связана с планированием, то использование такого доступа вполне оправдано. Если это не так, перед установкой выясните, зачем приложению нужен доступ к календарю. Запись событий календаря является обычным делом. Если неясно, зачем программе нужны эти настройки, описание в магазине Play должно рассказать вам больше. Если вы все ещё не уверены, спросите разработчика.

Phone Status And Identity

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

Важно знать, какой идентификатор запрашивает программа. Каждый телефон имеет идентификатор устройства, который отличается от любого другого, и его можно раскрыть, не передавая никакой личной информации. Когда вы видите, сколько людей используют определённую версию Android на графике от Google, они используют этот идентификатор устройства, чтобы помочь получить эти цифры. Когда вы заходите в Google Play и скачиваете программу, вас подсчитывают, и при этом только один раз. Идентификатор смартфона также является лучшим способом для синхронизации облачных данных и настроек ПО со смартфоном. Разрешение указывает только на то, какой у вас телефон и какое на нём программное обеспечение, поэтому ваши данные не будут доступны.

Разрешение также позволяет прочитать другой уникальный идентификатор – IMEI. Номер IMEI – это то, как телефонная компания подключает телефон – ваш адрес, ваше имя и всё остальное, что вам нужно будет предоставить, чтобы купить телефон, который сможет доказать, кто вы. Эти данные трудно получить – между ними и любыми данными вашей учётной записи есть минимум три разных защищённых и зашифрованных сервера базы данных, но получить доступ к ним не невозможно. Поскольку у вас нет возможности узнать, какой идентификатор требует приложение, выберите «Нет», если не знаете, почему разработчики этого хотят и что они с ним делают.

GPS и сетевое местоположение

Если приложение должно знать, где вы находитесь, оно должно запросить ваше местоположение. Есть два вида местоположения – неточное и точное. Первый вариант подходит для большинства рядовых ситуаций, но иногда требует точное местоположение. Потребность в вашем точном местоположении может быть определена простым запросом. Например, когда приложение должно знать, что находится в радиусе 50 м. Здесь необходимо точное местоположение. Точное местоположение необходимо и программам, которые, например, показывают, где находятся супермаркеты с оборудованным для инвалидов входом или лифтами. А вот простые программы для совершения покупок не требуют точного местоположения, в отличие от навигационных карт.

Изменять/Удалять содержимое SD-карты

Это разрешение, которое позволяет приложению читать или записывать данные на внешнюю память смартфона. Необходимо, чтобы дать приложению возможность свободно просматривать данные, изменять их, удалять и добавлять дополнительную информацию данные в любое место на SD-карте. Сбивает с толку тот факт, что под SD-картой подразумевается не только флешка. В файловой системе Android память телефона также называется SD-картой. Google многое сделал, чтобы сделать это разрешение безвредным. В каждой версии они уточняют, как приложение может получить доступ только к той информации, которая ему нужна. Но все ещё есть пользователи, использующие старые версии программ и ОС. Если вы один из них, убедитесь, что вы доверяете приложению, прежде чем устанавливать его. Любое приложение, написанное для API уровня 4 (Android 1.6 Donut) или ниже, получает это разрешение по умолчанию. Таких приложений не так много. Какой вред это может принести, зависит от того, какие данные хранятся в памяти вашего телефона. Телефоны под управлением Android 7 Nougat и приложения, созданные для телефонов под управлением Android 7, используют доступ к каталогу в заданной области, что гораздо удобнее и безопаснее.

Полный доступ к сети

Это разрешение означает именно то, что оно говорит. Приложение хочет иметь возможность отправлять запросы и получать ответ через сеть (Wi-Fi или подключение для передачи данных по мобильной сети). Помимо приложений, которые используют Интернет для чего-то очевидного, в них нуждаются в этом приложения с рекламой. Разрешение довольно безвредное, но, когда речь заходит о вашей личной информации, оно может использовать данные без вашего ведома. Мы ненавидим платить за дополнительные данные так же, как и вы. Если вы найдёте приложение, которое должно работать в автономном режиме, но не работает, удалите его.

Как удалить App Permissions

Чтобы найти свои приложения и их разрешения на Android, откройте «Настройки», а затем нажмите «Приложения и уведомления», «Информация о приложении» и выберите интересующее вас приложение. Выберите пункт «Разрешения», чтобы просмотреть, какими из них обладает приложение. Вы можете отключить любое из них в любое время, передвинув переключатель рядом с этой записью. Другой вариант – просматривать по разрешению, а не по приложению. Откройте «Настройки» и перейдите в раздел «Приложения и уведомления», как и в предыдущем случае. Но на этот раз выберите «Разрешения приложения». Откроется список разрешений, который включает датчики, календарь, камеру, контакты, местоположение, микрофон, SMS, память, телефон и многое другое. Нажмите любую запись, чтобы увидеть, какие приложения могут получить доступ к этой функции. Здесь также с помощью переключателей можно убрать любые настройки. Прежде чем начинать отключать разрешения, помните, что для выполнения своей работы некоторые приложения полагаются на этот доступ. Например, если приложение может просматривать ваши контакты, оно использует их, чтобы помочь вам обмениваться контентом, файлами или приглашать друзей на мероприятия, а не собирать ваши данные для получения прибыли.

Разрешения при загрузке софта

Когда вы загружаете программы из Play Store, некоторые из них перед установкой запрашивают разрешение на использование информации. При загрузке приложений, созданных для Android 6.0 и более поздних версий, вы можете предоставить или запретить разрешения непосредственно во время установки. Чтобы просмотреть разрешения той или иной утилиты перед установкой, сделайте следующее:

  1. Откройте приложение Play Store.
  2. Перейти на страницу сведений о приложении. Чтобы просмотреть разрешения перед установкой, пролистайте до раздела «Разработчик» и нажмите «Сведения о разрешениях».
  3. Нажмите «Установить».

Некоторые приложения будут установлены сразу. Вы можете разрешить или запретить отдельные запросы на разрешение до того, как приложение будет использовать данные такого типа. Для других программ в Google Play отображаются все группы разрешений, к которым она сможет получить доступ перед установкой. Эта информация может помочь вам решить, хотите ли вы установить её.

Если приложение уже установлено

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

  1. Откройте приложение Play Store.
  2. Нажмите кнопку Меню – Мои приложения и игры – Установленные.
  3. Выберите приложение.
  4. Нажмите Больше (вертикальная линия из 3-х точек).
  5. Снимите флажок «Автообновление», если он ещё не снят.

Чтобы отключить автообновление для всех приложений:

  1. Откройте приложение Play Store.
  2. Нажмите кнопку Меню – Настройки – Автообновление приложений – Никогда не обновлять автоматически.

Есть также много других, менее подозрительных разрешений. Приложение, которое делает снимки, должно контролировать ваше оборудование. Netflix должен держать ваш экран активным в течение всего времени, пока вы его не касаетесь. Виджет профиля звонков нуждается в доступе к вашим настройкам. Разобраться с разрешением, которое кажется неуместным, обычно помогает немного логики. Если нет, то читайте комментарии в Google Play и задавайте вопросы на форумах. Большинство приложений в Google Play не могут украсть ваши данные или ваши деньги. Помните, что большинство людей, пишущих приложения, просто хотят заработать немного денег или делают это ради удовольствия. Приложений, которые существуют для обработки ваших данных, не так много. Но иногда разработчики допускают ошибку – нетрудно заставить Android запрашивать разрешение, которое не используется приложением, и легко игнорировать эти ошибки при их создании.

App Permissions – что это на Андроид

При включении смартфона в верхней строке статуса может быть нарисован замочек. При нажатии — выскакивает ошибка, в тексте которой упоминается Permission Control (идентификатор com.mediatek.security).

Удалось выяснить

По мнению одного юзера, Permission Control — контроль разрешений для приложений. Данный компонент способен вызывать глюки, лаги, нестабильную работу телефона, увеличенный расход батареи. Для отключения необходимо перейти в настройки > безопасность, найти пункт App Permission > отключить.

Опасность отключенного приложения состоит в том, что все программы получат полные разрешения. Рекомендуется перед отключением просканировать смарт на наличие вирусов/троянов. Для проверки можно использовать антивирусы Касперского, Доктора Веба.

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

Приложение в списке установленных:

Также может быть ошибка:

permission control произошла ошибка

Можно попробовать данное приложение заморозить при помощи Titanium Backup. Удалять не стоит — могут быть проблемы. Приложение в Титаниуме:

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

Apps will directly get permissions without your confirmation

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

Также после отключения могут быть проблемы с Play Market (скорее всего связаны с безопасностью).

Еще один человек подтвердил — если вас достает приложение Permission Control, выключите в настройках > безопасность > разрешения для приложений.

Дополнительно удалось выяснить — за запуск сторонних приложений отвечает не только Phone Cleaner (необходим для энергосбережения), но и плагин Permission Control.

Если Permission Control заморозить Титаниумом тогда автостарт в настройках станет неактивным.

По непроверенной информации Permission Control это тоже самое что и Privacy Protect.

Читать еще:  На экране планшета андроид с восклицательным знаком

Чтобы приложение пермиссион вас больше не доставало, можно поставить галочку Больше не уведомлять.

Другой пользователь написал свой способ отключения

  1. Открываете патчер Lucky Patcher, выбираете Permission control.
  2. Чистим кэш. Останавливаем.
  3. Заморозить. В связи с тем что приложение системное — рекомендуется сделать бэкап.

Другой чел написал, что он решил проблему через Гравицапу — там есть блокировка уведомлений.

Странный косяк — когда приложение пытается использовать GPS, то пермиссион контрол отображает GPS как Bluetooth.

На главную! 07.12.2018 «> Читать! —>

Что это такое?

App Permissions Manager (или App ops) – это менеджер уровня разрешений, работающий c ОС Android 4.3 и выше. Приложение создает свою картотеку всего софта на смартфоне. По отдельности может блокировать доступ приложений к разной запрашиваемой информации, к примеру: данным GPS, истории браузера, хранящимся текстовым сообщениям и т.д. Очень удобный интерфейс позволяет в один клик запрещать передачу данных сторонним ресурсам, что очень эффективно против разных шпионских программ.

Приложение App Permissions Manager для Андроид

Преимущества менеджера

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

Также к огромным плюсам можно отнести работу в реальном времени. Зайдя в «App Permissions» и отключая разные характеристики, они тут же вступают в силу. Не нужно производить перезагрузку девайса, все уже будет применено на деле. А процесс запрета происходит посредством перетаскивания ползунка с одной стороны в другую. Все действительно очень просто и не требует особых навыков от пользователя. Для полноценной работы программы, на Андроиде требуется активный root-доступ.

Весь интерфейс состоит из списка приложений, где возможно установить ограничение на доступ к личной информации. Вверху имеется навигационное меню: Device, Personal, Location, Messaging. Никаких дополнительных настраиваемых меню больше нет.

Внимание! Не стоит путать работу этого приложения со всплывающими уведомлениями в версии Андроид 6.0 и выше – “App Permission Management is running” (настройки APM активированы) и “App Permission Management is closed” (настройки APM отключены). Убрать (отключить) уведомления можно в “Настройках” – “Безопасность” (листаем вниз) – перемещаем ползунок против “Разрешения приложений”. Если уведомление появляется при запуске определенного приложения, тогда войдите в его сведения в Диспетчере приложений и там в пункте “Разрешения” активируйте или снимите все ползунки.

Уведомление App Permission Management is running

Как инсталлировать в смартфон

Распространяется «App Permissions Manager» официально через Google Play. Он совершенно бесплатный, поэтому нет смысла скачивать его с других источников в интернете. Сам процесс установки ничем не отличается от стандартного приложения, всего в пару кликов все уже будет инсталлировано к вам в телефон. Аналогов также предостаточно в Маркете, но качество их не всегда лучшее.

Похожие статьи

Что это такое?

App Permissions Manager (или App ops) – это менеджер уровня разрешений, работающий c ОС Android 4.3 и выше. Приложение создает свою картотеку всего софта на смартфоне. По отдельности может блокировать доступ приложений к разной запрашиваемой информации, к примеру: данным GPS, истории браузера, хранящимся текстовым сообщениям и т.д. Очень удобный интерфейс позволяет в один клик запрещать передачу данных сторонним ресурсам, что очень эффективно против разных шпионских программ.

Приложение App Permissions Manager для Андроид

Преимущества менеджера

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

Также к огромным плюсам можно отнести работу в реальном времени. Зайдя в «App Permissions» и отключая разные характеристики, они тут же вступают в силу. Не нужно производить перезагрузку девайса, все уже будет применено на деле. А процесс запрета происходит посредством перетаскивания ползунка с одной стороны в другую. Все действительно очень просто и не требует особых навыков от пользователя. Для полноценной работы программы, на Андроиде требуется активный root-доступ.

Весь интерфейс состоит из списка приложений, где возможно установить ограничение на доступ к личной информации. Вверху имеется навигационное меню: Device, Personal, Location, Messaging. Никаких дополнительных настраиваемых меню больше нет.

Внимание! Не стоит путать работу этого приложения со всплывающими уведомлениями в версии Андроид 6.0 и выше — «App Permission Management is running» (настройки APM активированы) и «App Permission Management is closed» (настройки APM отключены). Убрать (отключить) уведомления можно в «Настройках» — «Безопасность» (листаем вниз) — перемещаем ползунок против «Разрешения приложений». Если уведомление появляется при запуске определенного приложения, тогда войдите в его сведения в Диспетчере приложений и там в пункте «Разрешения» активируйте или снимите все ползунки.

Уведомление App Permission Management is running

Как инсталлировать в смартфон

Распространяется «App Permissions Manager» официально через Google Play. Он совершенно бесплатный, поэтому нет смысла скачивать его с других источников в интернете. Сам процесс установки ничем не отличается от стандартного приложения, всего в пару кликов все уже будет инсталлировано к вам в телефон. Аналогов также предостаточно в Маркете, но качество их не всегда лучшее.

В момент, когда устройство переходит в состояние IDLE:

  • Доступ приложению к сети отключен, пока приложение не получит high-priority GCM-push.
  • Система игнорирует Wake lock’и. Приложения могут сколько угодно пытаться запросить пробуждение процессора — они их не получат.
  • Alarm’ы запланированные в AlarmManager не будут вызываться, кроме тех, которые будут обновлены с помощью setAndAllowWhileIdle().
  • Система не производит поиска сетей Wi-Fi.
  • NetworkPolicyManagerService: пропускает только приложения из белого списка.
  • JobSchedulerService: все текущие задачи отменяются. Новые откладываются до пробуждения.
  • SyncManager: все текущие отменяются, новые откладываются до пробуждения.
  • PowerManagerService: только задачи приложений из белого списка вызовутся.

Соответственно, если наше приложение чат, то мы можем отправить с сервера push с полем priority = high. А если у нас приложение будильник, то мы должны обязательно вызвать для Alarm setAndAllowWhileIdle() или setExactAndAllowWhileIdle(). Во многих других случаях мы вообще не должны об этом переживать, после того, как пользователь возьмет устройство в руки, все заснувшие alarm’ы и SyncAdapter’ы проснутся и сделают свою работу. (Да-да я знаю, что после выхода из doze mode все начинает синкаться и даже Nexus 9 минуты две тормозит) Но не только при попадании устройство в Doze Mode наши приложения будут лишены возможности разряжать батарею. Второй режим под название App Standby отправляет в такую же изоляцию приложения, которые не подходят под условия:

  • Пользователь явно запустил приложение.
  • Приложение имеет процесс, работающий в данный момент на переднем плане (Activity или foreground service, или используется другой activity или foreground service’ом).
  • Приложение создало уведомление, которое висит в списке уведомлений.
  • Пользователь принудительно добавил приложение в список исключений оптимизации в настройках системы

Возможно сейчас разработчики коммерческих voip нервно начали продумывать, как запретить обновляться своим пользователям на пугающий своей жесткостью Android Marshmallow. Но не волнуйтесь, есть специальный Whitelist, в который пользователь руками может добавить исключения. Приложениям из Whitelist не страшны ни Doze Mode ни App Standby. Чтобы проверить, попало ли наше приложение в Whitelist вызываем метод isIgnoringBatteryOptimizations(). Пользователь может сам руками добавить/удалить из списка в настройках Settings > Battery > Battery Optimization Но мы можем его сами попросить с помощью интента ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS или запросив пермишен REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, который покажет диалог на автоматическое добавление в вайтлист с разрешения пользователя. Подробнее: developer.android.com/intl/ru/training/monitoring-device-state/doze-standby.html#support_for_other_use_casesnewcircle.com/s/post/1739/2015/06/12/diving-into-android-m-doze Мы подобрались к самому известному изменению в Android Marshmallow. Более того это изменение требует от нас наибольшего вовлечения в перелопачивание кода приложения. Кратко говоря: халява кончилась. Да-да, каждый раз, когда наше приложение обращается, например, с запросом на местоположение пользователя, мы должны проверить, есть ли у приложения разрешение от пользователя на это действие. Если есть — обращаемся к нужным нам системным ресурсам, если нет — запрашиваем. Так же пользователь может навсегда приложению запретить доступ, тогда единственный наш шанс — это попросить его самого зайти в настройки и снять запрет, показав ему объясняющее сообщение, зачем нам нужен доступ. Стоит отметить, что Permissions в Android делятся на два типа:

  1. Нормальные разрешения, вроде доступа к сети и bluetooth.
  2. Опасные разрешения. В этот список входят разрешения на: календарь, камеру, контакты, местоположение, микрофон, телефон, сенсоры, смс и внешнее хранилище

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

  • Описать только PROTECTION_NORMAL запросы в manifest
  • Пользователь их все подтвердит при установке
  • Когда приложению нужен доступ к одному или нескольким разрешениям из группы опасных, проверить, нет ли разрешения
  • Если разрешения нет — запросить
  • Если разрешения не будет — объяснить, на что это повлияет
  • Если разрешение получено — продолжить работу

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

Всем привет!
В этой статье мы рассмотрим три самых важных изменения в новом Android, которые не могут быть проигнорированы ни одним разработчиком, который поставил у себя в проекте targetSdk = 23 и выше.
Doze Mode — режим «отключки», в который переходят все устройства на Marshmallow после некоторого времени обездвижения без зарядки.
App Standby — автоматическое лишение приложений доступа к ресурсам устройства, всех которые давно не открывал пользователь.
Runtime Permissions — новая модель запроса разрешений. Теперь мы, как разработчики, каждый раз обращаясь, например, к микрофону устройства, должны проверять, есть ли у нашего приложения разрешение на доступ к нему.
В Google в новом релизе Android сделали очень важный шаг в сторону оптимизации работы батареи. Все мы знаем, как пользователи любят повонять в комментариях высказываниями: «Дурацкие Google Play Services» жрут 25% батареи моего ******* S III, гопники, верните мне мой драгоценный айфон, нет сил, терпеть издевательства от Гугл». Только вот эти пользователи не ставили себе никогда Battery Historian и не в курсе, что жрут батарею бесплатные игры от сомнительных авторов и такие же сделанные на коленке живые обои, например. Но пользователь этого не знает, и как бороться с кучей левых приложений, беcпощадно съедающих батарею, он не в курсе.

Ну теперь пользователям об этом заботиться и не придется. С приходом двух новых режимов Doze Mode и App Standby операционная система перекрывает кислород всем чрезмерно жрущим заряд приложениям. Как? Читаем далее:

Когда устройство на Android Marshmallow лежит без движения и без зарядки, спустя час оно переходит в Doze Mode. Режим отключки, когда почти все приложения перестают жрать батарею.

Это происходит не сразу, а по шагам:

ACTIVE — Устройство используется или на зарядке
INACTIVE — Устройство недавно вышло из активного режима (пользователь выключил экран, выдернул зарядку и т.п.)
. 30 минут
IDLE_PENDING — Устройство готовится перейти в режим ожидания
. 30 минут
IDLE — Устройство в режиме бездействия
IDLE_MAINTENANCE — Открыто короткое окно, чтобы приложения выполнили свою работу

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

В момент, когда устройство переходит в состояние IDLE:

  • Доступ приложению к сети отключен, пока приложение не получит high-priority GCM-push.
  • Система игнорирует Wake lock’и. Приложения могут сколько угодно пытаться запросить пробуждение процессора — они их не получат.
  • Alarm’ы запланированные в AlarmManager не будут вызываться, кроме тех, которые будут обновлены с помощью setAndAllowWhileIdle().
  • Система не производит поиска сетей Wi-Fi.
  • NetworkPolicyManagerService: пропускает только приложения из белого списка.
  • JobSchedulerService: все текущие задачи отменяются. Новые откладываются до пробуждения.
  • SyncManager: все текущие отменяются, новые откладываются до пробуждения.
  • PowerManagerService: только задачи приложений из белого списка вызовутся.

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

Во многих других случаях мы вообще не должны об этом переживать, после того, как пользователь возьмет устройство в руки, все заснувшие alarm’ы и SyncAdapter’ы проснутся и сделают свою работу. (Да-да я знаю, что после выхода из doze mode все начинает синкаться и даже Nexus 9 минуты две тормозит)

Но не только при попадании устройство в Doze Mode наши приложения будут лишены возможности разряжать батарею. Второй режим под название App Standby отправляет в такую же изоляцию приложения, которые не подходят под условия:

  • Пользователь явно запустил приложение.
  • Приложение имеет процесс, работающий в данный момент на переднем плане (Activity или foreground service, или используется другой activity или foreground service’ом).
  • Приложение создало уведомление, которое висит в списке уведомлений.
  • Пользователь принудительно добавил приложение в список исключений оптимизации в настройках системы

Возможно сейчас разработчики коммерческих voip нервно начали продумывать, как запретить обновляться своим пользователям на пугающий своей жесткостью Android Marshmallow. Но не волнуйтесь, есть специальный Whitelist, в который пользователь руками может добавить исключения. Приложениям из Whitelist не страшны ни Doze Mode ни App Standby.

Чтобы проверить, попало ли наше приложение в Whitelist вызываем метод isIgnoringBatteryOptimizations().

Пользователь может сам руками добавить/удалить из списка в настройках Settings > Battery > Battery Optimization
Но мы можем его сами попросить с помощью интента ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS или запросив пермишен REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, который покажет диалог на автоматическое добавление в вайтлист с разрешения пользователя.

Мы подобрались к самому известному изменению в Android Marshmallow. Более того это изменение требует от нас наибольшего вовлечения в перелопачивание кода приложения. Кратко говоря: халява кончилась.

Читать еще:  Как настроить камеру на планшете андроид

Да-да, каждый раз, когда наше приложение обращается, например, с запросом на местоположение пользователя, мы должны проверить, есть ли у приложения разрешение от пользователя на это действие. Если есть — обращаемся к нужным нам системным ресурсам, если нет — запрашиваем. Так же пользователь может навсегда приложению запретить доступ, тогда единственный наш шанс — это попросить его самого зайти в настройки и снять запрет, показав ему объясняющее сообщение, зачем нам нужен доступ.

Стоит отметить, что Permissions в Android делятся на два типа:

  1. Нормальные разрешения, вроде доступа к сети и bluetooth.
  2. Опасные разрешения. В этот список входят разрешения на: календарь, камеру, контакты, местоположение, микрофон, телефон, сенсоры, смс и внешнее хранилище

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

И так последовательность наших шагов:

  • Описать только PROTECTION_NORMAL запросы в manifest
  • Пользователь их все подтвердит при установке
  • Когда приложению нужен доступ к одному или нескольким разрешениям из группы опасных, проверить, нет ли разрешения
  • Если разрешения нет — запросить
  • Если разрешения не будет — объяснить, на что это повлияет
  • Если разрешение получено — продолжить работу

Чтобы проверить доступность разрешения дергаем ContextCompat.checkSelfPermission (Context context, String permission).
Чтобы запросить разрешения, показав системный диалог, вызывываем ActivityCompat.requestPermissions();
Результат этого запроса придет в асинхронный колбэк в активити onRequestPermissionsResult(), в нем мы узнаем решение пользователя по каждому из запрошенных разрешений.

Запрашивать лишь те разрешения, которые действительно нужны. До сих пор в Google Play находятся разработчики, которые запрашивают все подряд
Если есть возможность, вместо запроса воспользоваться внешним Intent. Например, для фото или видео часто нет смысла встраивать камеру в приложение, гораздо проще воспользоваться внешним приложением
Запрашивать разрешение, только перед тем, когда оно понадобится. Запрашивать при старте приложения все разрешения нелогично (из тех, которые нам нужны), их смысл как раз в том, что мы запрашиваем их в контексте их использования.Например, пользователю становится понятно зачем его банковскому клиенту доступ к контактам — чтобы выбрать одного при шаринге по ФИО
Пояснять пользователю, для чего запрашивается разрешение. Если пользователь все же запретил приложению доступ, а без него оно не может, оно должно максимально понятно объяснить, что без этого разрешения оно работать дальше не будет

Подробнее: developer.android.com/intl/ru/training/permissions/requesting.html
Подкаст о пермишенах: androidbackstage.blogspot.ru/2015/08/episode-33-permission-mission.html
Семпл от Google: developer.android.com/intl/ru/samples/RuntimePermissions/index.html
Мой семпл на github: github.com/nekdenis/Permissions_sample

Сегодня мы поговорили о самых заметных изменениях в Android Marshmallow. На днях я добавлю статью про остальные фичи и изменения, важные для нас, как для разработчиков. Спасибо за внимание и скорейшую оптимизацию ваших приложений под новый Android!

[:ru]Android runtime permissions пример реализации[:en]Android runtime permissions example implementation[:]

[:ru]В этом уроке мы рассмотрим, что такое запросы разрешений во время исполнения приложения и как с ними работать. Я покажу, как инициировать запрос разрешения, как обрабатывать ответы пользователя, а также что делать, если пользователь отказал в разрешении и установил флаг «больше не спрашивать» в диалоге запроса разрешения.

Кто не в теме, немного теории:

Как вы помните, до версии Android 6.0 все запрашиваемые разрешения отображались пользователю при установке приложения. И если пользователь не предоставлял приложению хотя бы одно разрешение из списка, приложение не устанавливалось.

Теперь все изменилось.

Начиная с Android API 23 разрешения поделили на обычные (normal) и опасные (dangerous).

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

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

Полный список обычных и опасных разрешений можно посмотреть по ссылке.

Во вторых, в связи с этим изменилось поведение приложений при установке, и здесь возможны варианты.

Например, рассмотрим случай, когда устройство работает под управлением Android версии 5.1 или ниже, или целевая версия SDK в файле сборки приложения имеет значение 22 или ниже.

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

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

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

Теперь давайте рассмотрим пример работы с разрешениями на практике.

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

Исходный код этого проекта вы можете посмотреть ниже:

В макете экрана одна кнопка.

Также нужен идентификатор для корневого view, это понадобится для работы снекбара.

Поскольку снекбар является компонентом библиотеки материального дизайна, добавьте ее в зависимости файла сборки модуля проекта.

Также нам понадобится разрешение на запись в память, пропишем его в манифесте.

Теперь рассмотрим код класса MainActivity.

Константа PERMISSION_REQUEST_CODE хранит произвольное значение, по которому в дальнейшем можно определить, на какой запрос разрешения вам пришел ответ.

Аналогично мы получали результат от activity, используя startActivityForResult, вспоминаем уроки по этой теме на нашем канале StartAndroid.

В методе onCreate создадим кнопку и присвоим ей слушатель нажатия.

В методе onClick проверяем логический результат метода hasPermissions, и вызываем метод создания папки, makeFolder. В этом методе мы просто создаем новый файл с именем fandroid и выводим несколько тостов с сообщениями, в зависимости от того, удалось или не удалось создать файл, или он уже создан.

Если же результат в методе onClick равен false, то вызываем метод requestPermissionWithRationale, который будет в свою очередь вызывать метод запроса разрешения. Мы перейдем к нему позже.

Ниже метод hasPermissions, который с помощью метода checkCallingOrSelfPermission в цикле проверяет предоставленные приложению разрешения и сравнивает их с тем, которое нам необходимо.

При отсутствии разрешения метод будет возвращать false, а при наличии разрешения — true.

В методе requestPerms создаем массив permissions , который содержит ссылки на константы класса Manifest с кодами разрешений. Поскольку используется массив, то одновременно можно запрашивать несколько разрешений.

После проверки версии устройства Запрос разрешения выполняет метод requestPermissions, которому мы передаем массив нужных нам разрешений и константу PERMISSION_REQUEST_CODE

После вызова этого метода пользователю отображается диалоговое окно с запросом разрешения.

Ответ пользователя приходит в метод onRequestPermissionsResult. Параметры requestCode и permissions содержат данные, которые вы передавали при запросе разрешений. Основные данные здесь несет массив grantResults, в котором находится информация о том, получены разрешения или нет. Каждому i-му элементу permissions соответствует i-ый элемент из grantResults.

Здесь мы обрабатываем ответ — проверяем, если разрешение предоставлено пользователем, о чем будет свидетельствовать ответ PERMISSION_GRANTED, то вызываем метод makeFolder, а если нет, то проверяем версию устройства,

и если она равна Андроид 6.0 или выше — проверяем, отказывался ли ранее пользователь предоставлять это разрешение. В таком случае метод с длинным названием shouldShowRequestPermissionRationale вернет нам true.

Одной из проблем может стать опция “Don’t ask again”, которая появляется при повторном запросе разрешения. При её выборе диалог запроса не будет больше появляться.

Метод shouldShowRequestPermissionRationale в таком случае будет возвращать false, а в onRequestPermissionsResult будет получен результат PERMISSION_DENIED — отказ в получении разрешения.

И останется единственный способ — попросить пользователя включить разрешение непосредственно через настройки приложения в разделе Permissions.

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

настройки открывает метод openApplicationSettings(), где мы создаем и отправляем соответствующий интент. В примере используются startActivityForResult и onActivityResult чтобы определить, что пользователь вернулся из activity настроек обратно в приложение и попробовать выполнить действие, которое нельзя было сделать без нужного разрешения.

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

это мы обыграем в методе requestPermissionWithRationale() — Запрос разрешения с обоснованием

Здесь также проверяем ответ метода shouldShowRequestPermissionRationale и если он true, создаем снекбар с сообщением для пользователя и кнопкой, по нажатию на которую будем вызывать метод получения разрешения.

Здесь же будет вызываться метод получения разрешения в случае первого запроса.

Теперь установим приложение на устройство и проверим его работу на эмуляторе с Андроид 6.0 (процесс тестирования смотрите в видео выше).

При нажатии кнопки появляется запрос разрешения.

Если пользователь отказал, то приложение продолжает работу, но папка не создается.

При повторном нажатии кнопки всплывает снекбар с объяснением необходимости предоставления запроса и кнопкой, при нажатии которой вновь отображается запрос.

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

После установки разрешения и возврата в приложение папка успешно создается.

На этом все. Вопросы задавайте в комментариях к уроку.[:en]In this lesson we will look at what the permission requests during the execution of the application and how to work with them. I’ll show you how to initiate a request for permission, how to handle the user’s answers and what to do if the user refused permission and planted the flag of «don’t ask» in the dialog asking permission.

In my life, a little theory:

As you remember, to Android 6.0, all the requested permissions is displayed to the user when the application is installed. And if the user does not provide the application to at least one solution from the list, the application could not be installed.

Now everything has changed.

Starting with Android 23 API permissions were divided into normal (normal) and hazardous (dangerous).

Regular permissions are those that are not a direct threat to user privacy. These include permissions to access Internet and network connections, access to wireless modules, management alerts, sound, etc.

Threat to include permissions to access calendar, camera, contacts, location, microphone, calls, SMS, sensors, as well as permission to read and write data to the external memory device.

Full list of normal and dangerous permissions, you can view the link.

Secondly, in connection with this changed the behavior of applications when you install, there may be options.

For example, consider the case when the device is running Android version 5.1 or lower, or target SDK version in the Assembly file of the application has a value of 22 or below.

When you install this app all the usual permissions specified in the manifest will be provided without prompting.
If the manifest is a dangerous permission to grant you will be prompted to the user. And if the user refuses, the application will not be installed.

If the device is running Android 6.0 or higher, or target SDK version set to 23 or higher, the application can be installed without your permission requests. But it received only conventional, safe solutions.

Dangerous permissions may be requested at the time of the application, when the user tries to use a feature that requires this permission. The user may refuse permission and the app will quietly continue to work with limited functions.

Now let’s look at an example of working with permissions in practice.

This application with one button which creates a folder in the storage device for which the app needs permission to write to external memory.

The source code of this project you can watch below:

Системные разрешения

Android это система с разделением прав, в которой каждое приложение запущено с индивидуальным идентификатором (ID пользователя и ID группы системы Linux). Части системы также содержат собственные идентификаторы. Таким образом, Linux изолирует приложения друг от друга и от системы.

Дополнительные функции безопасности предоставляют механизм “разрешений”, который усиливает ограничения на доступ к операциям, которые определенный процесс может выполнять. Также выдаются разрешения для каждого URI для предоставления индивидуального доступа к определенным частям данных.

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

Архитектура безопасности

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

Читать еще:  Работа планшета от сети без аккумулятора

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

Изолированная среда приложения не зависит от технологии, используемой при сборке. В частности, виртуальная машина Dalvik не является преградой для выполнения приложением нативного кода (смотрите Android NDK). Все типы приложений – Java, нативные и гибридные – запускаются в одинаковых песочницах и защищены одинаково.

Подпись приложения

Все APK файлы должны быть подписаны сертификатом, закрытый ключ которого хранится у их разработчика. Данный сертификат идентифицирует автора приложения. Сертификаты не обязательно должны быть подписаны центром сертификации; это совершенно допустимо и характерно для Android приложений – использовать собственные сертификаты. Они позволяют системе предоставлять или отказывать в доступе приложениям с подписанным уровнем доступа, а также разрешать или отказывать приложениям иметь такой-же идентификатор, как у другого приложения.

Идентификаторы пользователя и доступ к файлам

Во время установки, Android назначает каждому пакету уникальный идентификатор пользователя Linux (UID). Идентификатор остается постоянным на всё время существования пакета на этом устройстве. На другом устройстве тот же пакет может иметь другой UID; важно, чтобы каждый пакет на данном устройстве имел свой собственный идентификатор пользователя.

Поскольку управление безопасностью происходит на уровне процесса, код любых двух пакетов не может нормально работать в одном и том же процессе, так как они должны выполняться под различными пользователями Linux. Вы можете использовать атрибут sharedUserId в файлах манифеста для нескольких пакетов, чтобы указать общий UID. После этого в целях безопасности, два пакета будут выполняться как одно и тоже приложение, с одинаковым UID и одинаковыми правами на файлы. Помните, что в целях безопасности, только два приложения с одинаковой подписью (и хранящие одинаковый атрибут sharedUserId) будут иметь одинаковый идентификатор пользователя.

Любые данные, которые сохраняет приложение, будут связаны с идентификатором приложения и в нормальных условиях будут недоступны другим пакетам. При создании нового файла с использованием методов getSharedPreferences(String, int), openFileOutput(String, int) или openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory), вы можете использовать флаги MODE_WORLD_READABLE и MORE_WORLD_WRITEABLE, чтобы разрешить другим пакетам читать или записывать данный файл. При установке данных флагов, файл все еще принадлежит приложению, но он глобально доступен для чтения и записи любым приложением.

Использование разрешений

Стандартное Android приложение не имеет разрешений, связанных с ним по умолчанию, то есть оно не может сделать ничего, что могло бы негативно повлиять на пользователя или на какие-либо данные. Для использования защитных функций устройства, вы должны включить в файл AndroidManifest.xml один или несколько тегов , указав таким образом разрешения, которые вам нужны.

Например, если приложение должно отслеживать входящие SMS сообщения:

Во время установки приложения, запрошенные разрешения предоставляются на основе проверок подписи приложения и взаимодействия с пользователем. Во время выполнения приложения никакие проверки разрешений с уведомлением пользователя не проводятся; если приложению выдано конкретное разрешение на этапе установки, оно может его использовать по желанию в любое время. Если разрешение не выдано, любая попытка использовать функцию отменяется без уведомления пользователя.

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

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

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

Особые разрешения могут быть выполнены в нескольких местах во время работы приложения:

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

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

Например, разрешение WRITE_EXTERNAL_STORAGE было добавлено в API 4, чтобы закрыть доступ к общему хранилищу. Если вы установите targetSdkVersion равное 3 или ниже, на новых версиях Android это разрешение будет автоматически добавлено приложению.

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

Чтобы предотвратить такое поведение и удалить разрешения, в которых приложение не нуждается, всегда устанавливайте targetSdkVersion в максимально возможное значение. Какие разрешения добавлялись в каждой из версий, вы можете посмотреть в документации Build.VERSION_CODES.

Объявление и требование разрешений

Чтобы требовать собственное разрешение, вы должны сначала объявить его в файле манифеста, используя элемент

Например, приложение должно контролировать, кто может запустить одно из его явлений. Для этого объявим новое разрешение следующим образом:

Информационный портал по безопасности

Информационный портал по безопасности » Программирование » Веб-разработка » Android 6.0: Doze Mode, App Standby, Runtime Permissions. Всё, что необходимо знать каждому разработчику

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

Автор: admin от 3-11-2015, 10:43, посмотрело: 438

Всем привет!
В этой статье мы рассмотрим три самых важных изменения в новом Android, которые не могут быть проигнорированы ни одним разработчиком, который поставил у себя в проекте targetSdk = 23 и выше.
Doze Mode — режим «отключки», в который переходят все устройства на Marshmallow после некоторого времени обездвижения без зарядки.
App Standby — автоматическое лишение приложений доступа к ресурсам устройства, всех которые давно не открывал пользователь.
Runtime Permissions — новая модель запроса разрешений. Теперь мы, как разработчики, каждый раз обращаясь, например, к микрофону устройства, должны проверять, есть ли у нашего приложения разрешение на доступ к нему.

В Google в новом релизе Android сделали очень важный шаг в сторону оптимизации работы батареи. Все мы знаем, как пользователи любят повонять в комментариях высказываниями: «Дурацкие Google Play Services» жрут 25% батареи моего ******* S III, гопники, верните мне мой драгоценный айфон, нет сил, терпеть издевательства от Гугл». Только вот эти пользователи не ставили себе никогда Battery Historian и не в курсе, что жрут батарею бесплатные игры от сомнительных авторов и такие же сделанные на коленке живые обои, например. Но пользователь этого не знает, и как бороться с кучей левых приложений, беcпощадно съедающих батарею, он не в курсе.

Ну теперь пользователям об этом заботиться и не придется. С приходом двух новых режимов Doze Mode и App Standby операционная система перекрывает кислород всем чрезмерно жрущим заряд приложениям. Как? Читаем далее:

Когда устройство на Android Marshmallow лежит без движения и без зарядки, спустя час оно переходит в Doze Mode. Режим отключки, когда почти все приложения перестают жрать батарею.

Это происходит не сразу, а по шагам:

ACTIVE — Устройство используется или на зарядке
INACTIVE — Устройство недавно вышло из активного режима (пользователь выключил экран, выдернул зарядку и т.п.)
. 30 минут
IDLE_PENDING — Устройство готовится перейти в режим ожидания
. 30 минут
IDLE — Устройство в режиме бездействия
IDLE_MAINTENANCE — Открыто короткое окно, чтобы приложения выполнили свою работу

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

В момент, когда устройство переходит в состояние IDLE:

  • Доступ приложению к сети отключен, пока приложение не получит high-priority GCM-push.
  • Система игнорирует Wake lock’и. Приложения могут сколько угодно пытаться запросить пробуждение процессора — они их не получат.
  • Alarm’ы запланированные в AlarmManager не будут вызываться, кроме тех, которые будут обновлены с помощью setAndAllowWhileIdle().
  • Система не производит поиска сетей Wi-Fi.
  • NetworkPolicyManagerService: пропускает только приложения из белого списка.
  • JobSchedulerService: все текущие задачи отменяются. Новые откладываются до пробуждения.
  • SyncManager: все текущие отменяются, новые откладываются до пробуждения.
  • PowerManagerService: только задачи приложений из белого списка вызовутся.

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

Во многих других случаях мы вообще не должны об этом переживать, после того, как пользователь возьмет устройство в руки, все заснувшие alarm’ы и SyncAdapter’ы проснутся и сделают свою работу. (Да-да я знаю, что после выхода из doze mode все начинает синкаться и даже Nexus 9 минуты две тормозит)

App Standby

Но не только при попадании устройство в Doze Mode наши приложения будут лишены возможности разряжать батарею. Второй режим под название App Standby отправляет в такую же изоляцию приложения, которые не подходят под условия:

  • Пользователь явно запустил приложение.
  • Приложение имеет процесс, работающий в данный момент на переднем плане (Activity или foreground service, или используется другой activity или foreground service’ом).
  • Приложение создало уведомление, которое висит в списке уведомлений.
  • Пользователь принудительно добавил приложение в список исключений оптимизации в настройках системы

Исключения

Возможно сейчас разработчики коммерческих voip нервно начали продумывать, как запретить обновляться своим пользователям на пугающий своей жесткостью Android Marshmallow. Но не волнуйтесь, есть специальный Whitelist, в который пользователь руками может добавить исключения. Приложениям из Whitelist не страшны ни Doze Mode ни App Standby.

Чтобы проверить, попало ли наше приложение в Whitelist вызываем метод isIgnoringBatteryOptimizations().

Пользователь может сам руками добавить/удалить из списка в настройках Settings > Battery > Battery Optimization
Но мы можем его сами попросить с помощью интента ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS или запросив пермишен REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, который покажет диалог на автоматическое добавление в вайтлист с разрешения пользователя.

Runtime Permissions

Да-да, каждый раз, когда наше приложение обращается, например, с запросом на местоположение пользователя, мы должны проверить, есть ли у приложения разрешение от пользователя на это действие. Если есть — обращаемся к нужным нам системным ресурсам, если нет — запрашиваем. Так же пользователь может навсегда приложению запретить доступ, тогда единственный наш шанс — это попросить его самого зайти в настройки и снять запрет, показав ему объясняющее сообщение, зачем нам нужен доступ.

Стоит отметить, что Permissions в Android делятся на два типа:

  • Нормальные разрешения , вроде доступа к сети и bluetooth.
  • Опасные разрешения . В этот список входят разрешения на: календарь, камеру, контакты, местоположение, микрофон, телефон, сенсоры, смс и внешнее хранилище

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

    И так последовательность наших шагов:

    • Описать только PROTECTION_NORMAL запросы в manifest
    • Пользователь их все подтвердит при установке
    • Когда приложению нужен доступ к одному или нескольким разрешениям из группы опасных, проверить, нет ли разрешения
    • Если разрешения нет — запросить
    • Если разрешения не будет — объяснить, на что это повлияет
    • Если разрешение получено — продолжить работу

    Чтобы проверить доступность разрешения дергаем ContextCompat.checkSelfPermission (Context context, String permission).
    Чтобы запросить разрешения, показав системный диалог, вызывываем ActivityCompat.requestPermissions();
    Результат этого запроса придет в асинхронный колбэк в активити onRequestPermissionsResult(), в нем мы узнаем решение пользователя по каждому из запрошенных разрешений.

    Запрашивать лишь те разрешения, которые действительно нужны. До сих пор в Google Play находятся разработчики, которые запрашивают все подряд
    Если есть возможность, вместо запроса воспользоваться внешним Intent. Например, для фото или видео часто нет смысла встраивать камеру в приложение, гораздо проще воспользоваться внешним приложением
    Запрашивать разрешение, только перед тем, когда оно понадобится. Запрашивать при старте приложения все разрешения нелогично (из тех, которые нам нужны), их смысл как раз в том, что мы запрашиваем их в контексте их использования.Например, пользователю становится понятно зачем его банковскому клиенту доступ к контактам — чтобы выбрать одного при шаринге по ФИО
    Пояснять пользователю, для чего запрашивается разрешение. Если пользователь все же запретил приложению доступ, а без него оно не может, оно должно максимально понятно объяснить, что без этого разрешения оно работать дальше не будет

    Сегодня мы поговорили о самых заметных изменениях в Android Marshmallow. На днях я добавлю статью про остальные фичи и изменения, важные для нас, как для разработчиков. Спасибо за внимание и скорейшую оптимизацию ваших приложений под новый Android!

  • Ссылка на основную публикацию
    Adblock
    detector