Android 17 Advanced Protection начнет жестко ограничивать доступ приложений к Android AccessibilityService: API смогут использовать только проверенные программы, отнесенные к категории инструментов доступности. Это важно не только для пользователей с повышенным риском атак, но и для банков, финтеха, корпоративной мобильной безопасности и всех, кто уже устал объяснять, почему «дайте приложению спецвозможности» почти всегда звучит как начало плохой истории.
Google объявила о новой мере безопасности 2 октября 2026 года, сообщает The Hacker News. Ограничение будет включаться при активации Advanced Protection — режима, который собирает в одном профиле усиленные защитные механизмы Android. По формулировке Google, в Android 17 доступ к AccessibilityService при включенной Advanced Protection будет автоматически разрешен только верифицированным приложениям, классифицированным как Accessibility Tools. Идея простая: сохранить нормальную работу экранных дикторов, голосового управления и других assistive-технологий, но закрыть один из самых популярных маршрутов для мобильного вредоносного ПО.
AccessibilityService в Android изначально создавался для полезных сценариев: читать элементы интерфейса, помогать управлять устройством без касаний, реагировать на события в приложениях. Проблема в том, что ровно эти возможности делают API слишком привлекательным для злоумышленников. Если вредоносное приложение убедит пользователя включить ему спецвозможности, оно получает шанс наблюдать за экраном, нажимать кнопки от имени пользователя, перехватывать элементы интерфейса и проводить действия без root-доступа. Для банковского трояна это почти подарочная упаковка.
Типовая атака выглядит буднично. Пользователь ставит приложение вне привычного доверенного сценария или получает подделку под полезную утилиту. Дальше его уговаривают включить accessibility-доступ: якобы для ускорения работы, защиты, оптимизации, помощи пожилым родственникам — фантазия у операторов malware не хуже, чем у маркетологов в конце квартала. После выдачи разрешения троян может инициировать перевод в банковском приложении, накрывать легитимные экраны фальшивыми формами входа, считывать ввод, мешать удалению приложения и выдавать себе дополнительные разрешения.
Google в последние годы уже пыталась давить эту схему с разных сторон. Компания блокировала возможность для sideloaded-приложений включать сервисы доступности, добавляла защиты во время телефонного звонка, чтобы пользователь не отключал Google Play Protect и не выдавал опасные разрешения под диктовку мошенника, а также дала разработчикам флаг accessibilityDataSensitive. С его помощью можно помечать элементы интерфейса как содержащие чувствительные данные, чтобы подозрительные сервисы не могли читать их или взаимодействовать с ними. Новый шаг в Android 17 Advanced Protection выглядит как логичное ужесточение: не пытаться каждый раз отличить плохое поведение от хорошего, а сузить круг приложений, которым вообще можно дать такой уровень доступа.
Важная деталь: речь идет не обо всех пользователях Android по умолчанию, а о тех, кто включает Advanced Protection. Это режим для людей и организаций, которым нужен более высокий порог защиты: журналистов, активистов, руководителей, администраторов, сотрудников финтеха, разработчиков с доступом к инфраструктуре, владельцев криптоактивов и всех, чьи устройства интересны не только рекламным SDK. Для корпоративных MDM-сценариев это тоже сигнал: Google продолжает выносить рискованные мобильные разрешения из зоны «пользователь сам нажал, значит все нормально» в зону управляемой политики.
Для разработчиков assistive-приложений изменение означает более строгую зависимость от классификации и проверки. Если продукт действительно является инструментом доступности, ему придется соответствовать ожиданиям платформы и проходить верификацию как Accessibility Tool. Если же приложение использовало AccessibilityService как удобный способ автоматизации интерфейса, обхода ограничений или сбора данных, в режиме Advanced Protection такой подход начнет ломаться. Особенно это касается утилит, которые годами жили в серой зоне между «помощником пользователя» и «слишком много прав для слишком расплывчатой пользы».
Android 17 принесет и другие функции в рамках усиленной защиты. Google упоминает Intrusion Logging — постоянное, privacy-preserving журналирование для расследования атак продвинутого spyware-класса. USB Protection должна снижать риск физического доступа через USB-подключение. Отключение WebGPU уменьшит поверхность для сложных браузерных эксплойтов. Failed Authentication Lock будет полностью блокировать устройство после неудачных попыток аутентификации, чтобы затруднить физический перебор и дальнейшее исследование. Еще одна функция, View Supporting Apps, покажет пользователю, какие установленные приложения проверяли статус Advanced Protection.
Отдельный практический момент касается приложений, которые хотят менять поведение при включенном усиленном режиме. Google говорит, что разработчики смогут получать уведомление о включенной Advanced Protection и автоматически активировать собственные дополнительные защитные функции. Для банковского приложения это может быть более агрессивная антифрод-проверка. Для корпоративного клиента — запрет рискованных действий. Для мессенджера или менеджера паролей — дополнительные барьеры перед экспортом данных или входом с нового устройства. Главное, чтобы продукт не превращал безопасность в аттракцион из бесконечных предупреждений, потому что пользователь быстро учится нажимать «разрешить» с закрытыми глазами.
У этого решения есть предсказуемая цена: часть легитимной автоматизации станет менее удобной, а разработчикам придется аккуратнее объяснять, зачем им доступ к спецвозможностям. Но для рынка мобильной безопасности направление понятно. Android постепенно закрывает самые щедрые API от приложений, которые не могут убедительно доказать, что им нужен такой уровень контроля. Следующий спор будет не о том, нужны ли ограничения, а о том, кто и по каким правилам решает, какое приложение достаточно «доступное», «проверенное» и безопасное для допуска к экрану пользователя.