Что делать, если не нажимается кнопка «Разрешить» в Android

Запрос разрешения, без которого антивирус будет слепым и беззубым

    Если у вас на устройстве установлен Android 6, то вы уже много раз нажимали кнопку «Разрешить» / „Allow“. А некоторые из вас в июне 2016 года столкнулись с проблемой, что кнопка разрешения не реагирует на тапы, а запрет работает нормально. Этой достаточно короткой записью я попробую указать на причины проблемы и рассказать решение. Если вам нужно только решение и вы пришли сюда по запросу из поисковой системы, то вот оно: «Удалите приложения, использующие оверлей и написанные не руками, а жопой. Чаще всего жизнь портит вот этот файловый менеджер: https://play.google.com/store/apps/details?id=com.rhmsoft.fm»

    Если вам интересна причина этого поведения, то добро пожаловать в статью.

    Изначальная вседозволенность в Android выливается в простоту заражения устройства и сложность лечения этого заражения. Есть вредоносные приложения, которые тянут с собой набор для рутования, рутуют устройства, прописываются в системные директории и «прикрывают дверь» за собой. Обнаружить такие вредоносы не так просто, а удалить ещё сложнее, потому что прав на это нет.

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

    Теперь к сути.

    Я рассказывал в лекции про Tapjacking. Суть в том, что тап по активити приложения может быть пробношено дальше. То есть когда приложение для управления яркостью и цветовой температурой AMOLED экранов работает, оно вешает своё активити поверх всего. На самом деле пользователь взаимодействует с приложением, а оно уже пробрасывает его тапы дальше и этим воспринимается, будто никакого перекрывающего активити и нет. Конечно, здесь очевидна опасность перекрытия приложений, запрашивающих пароли. Но для таких приложений доступна штатная защита, которая запретит такое перекрытие — использование флага FLAG_WINDOW_IS_OBSCURED. Так что если в вашем приложении есть запросы паролей или ввод конфидециальных данных, позаботьтесь о том, чтобы был использован FLAG_WINDOW_IS_OBSCURED.
    Однако некоторые вредоносные приложения использовали эту возможность иначе. На критичные запросы системы о предоставлении прав для чего-либо, например, разрешение установки приложений из недоверенных источников или запрос снятия прав Администратора устройства, они рисовали свой запрос поверх системного, перекрывая настоящие кнопки своими, поддельными. Пользователь нажимал на кнопку, как он видел, отказа, а тап пробрасывался на согласие, которое на самом деле было под этой кнопкой отказа. Или ещё проще — перекрывали оригинальный текст и писали свой, полностью меняющий логику в принятии ответа, вынуждая нажать настоящую «Разрешить»

    В июне 2016 Google выпустил очередное обновление безопасности, которое, кроме прочего, изменило поведение системы в случае перекрытия диалоговых окон.

 Elevation of Privilege Vulnerability in Framework UI

An elevation of privilege vulnerability in the Framework UI permission dialog window could enable an attacker to gain access to unauthorized files in private storage. This issue is rated as Moderate because it could be used to improperly gain "dangerous" permissions.

    В случае, если патч установлен, любое, даже частичное перекрытие диалоговых окон (разрешение какого-то пермишена, разрешение на захват видео и подобное) блокирует нажатие разрешающей кнопки. Пользователь может тыкать в неё сколько угодно и ничего не произойдёт. А вот кнопка запрета будет продолжать работать.
    Безусловно, полное отсуствие реакции на нажатие вводит пользователя в ступор. Такое решение нельзя назвать юзер френдли. Потому в июле 2016 года было мелкое изменение в логике. Заключается оно в том, что при нажатии на кнопку разрешения будет сообщение о том, что есть приложение, котрое накладывает оверлей и нужно забрать этот пермишен.

    На мой Nexus 7 второго поколения как раз прилетел на днях патч и я откладывал его установку для написания этой записи. Теперь я могу показать изменение поведения в июньском и июльском обновлении. Первое видео — июньский патч, который добавл блокировку кнопки при оверлее. Приложение — файловый менеджер, на который я дал ссылку в самом начале. На самом же деле это может быть любое другое приложение. Достаточно чтобы оно полностью или частично перекрывало системные диалоги. Даже абсолютно прозрачно.

 

     В конце ролика я запустил установку обновления. После обновления поведение стало несколько иным. Теперь система сообщает, что есть какое-то приложение, которое перекрывает диалог. Однако проблема в том, что само наличие пермишена вообще не означает, что приложение создаёт проблему. Проблема будет лишь тогда, когда перекрытие происходит в момент поднятия системного диалога. И приложений, использующие пермишен перекрытия, много!
    И более того, этот пермишен не доступн для изменения в свойствах самого приложения! Его можно увидеть и изменить только из отдельной настройки «Наложение поверх других окон» („Draw over other apps“). Это действительно неудобно и не понятно для пользователя. Надеюсь, в будущих обновлениях всё станет очевиднее.

    Одно и то же действие, а поведение немного отличается.

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

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