«WhatsApp проверяет флаг ADB_ENABLED и видит процессы UIAutomator2 в памяти» - это звучит как точное знание механизма антибана. На деле это реконструкция сообщества: реальные технические маркеры Android собраны в цепочку причин и следствий, которую никто не подтвердил со стороны Meta. Разберём, где заканчивается Android-документация и начинается форумная догадка.
Если вы строите ферму на 20–30 устройств и читаете советы «отключайте ADB после запуска скрипта», стоит понимать: это рекомендация, основанная на предположении о механизме детекта, а не на подтверждённом знании. Ставка на неверную причину бана означает, что вы чините не ту проблему - и фермы продолжают падать.
Здесь претензий нет - это задокументированная архитектура Android, не домыслы.
Settings.Secure.ADB_ENABLED и development_settings_enabled действительно существуют в Android и читаются через стандартный Settings.Secure.getInt().Это база. Дальше начинается зона предположений - как и в разборе сторонних APK.
Было:
WhatsApp проверяет системный флаг
Settings.Secure.ADB_ENABLED- обычные пользователи не держат его включённым годами.
Стало:
Флаг технически существует и доступен через системный API. Но публичных подтверждений, что именно WhatsApp его считывает и использует как антиспам-сигнал, нет - это гипотеза сообщества автоматизаторов, построенная на том, что такая проверка технически возможна.
Было:
UIAutomator2 устанавливает два фоновых пакета и мини-сервер - WhatsApp видит эти процессы в оперативной памяти.
Стало:
Современный Android (11+) существенно ограничил видимость чужих процессов и пакетов для сторонних приложений. Нет публичных доказательств, что WhatsApp получает доступ к списку процессов или памяти других приложений на актуальных версиях ОС.
Было:
Если 20 телефонов демонстрируют идентичные сетевые задержки и MTU пакетов - банится вся сетка.
Стало: этот тезис нужно убрать полностью - подтверждений ему нет, это форумная гипотеза без проверяемой методологии.
| Маркер | Существует технически | WhatsApp подтверждённо это использует |
|---|---|---|
ADB_ENABLED флаг |
Да [✓] | Не подтверждено |
Пакеты com.github.uiautomator в памяти |
Да [✓] | Не подтверждено |
| Порт UIAutomator2 (обычно 6790) | Да [~] | Не подтверждено |
| MTU и сетевой джиттер между устройствами | Технически измеримо [~] | Не подтверждено |
| TCP/IP fingerprint устройства | Технически измеримо [~] | Не подтверждено |
| Статус зарядки батареи | Технически доступно [~] | Не подтверждено |
| Архитектура WABA вместо ADB-фермы | - | Да - официально иная модель работы [✓] |
Ни одна строка из таблицы, кроме архитектуры WABA, не имеет официального подтверждения как реально используемый Meta сигнал.
Логика сообщества понятна и местами красива: ADB обязателен для UIAutomator2, флаг технически читаем, служебные пакеты технически обнаружимы - значит, видимо, WhatsApp так и делает. Это правдоподобная реконструкция, но не она.
Проблема в том, что Android 11+ резко ограничил доступ приложений к спискам чужих процессов и пакетов через политику Package Visibility. Среди разработчиков идёт спор: одни утверждают, что WhatsApp технически не может сканировать память сторонних программ без нарушения политик Google Play; другие считают, что мессенджер обходит это, опрашивая доступность конкретных интент-фильтров или сервисов автоматизации напрямую. Официального разрешения этого спора не существует - см. общий контекст серого транспорта.
Студия автоматизации развернула ферму из 30 смартфонов на Android 11, подключённых по USB к одному ПК и управляемых через UIAutomator2, с рандомизированными паузами 10–40 секунд между кликами. Через 40 минут после старта рассылки Meta заблокировала 27 из 30 аккаунтов. В логах команда зафиксировала совпадение тестовых пакетов UIAutomator в памяти всех устройств и идентичный MTU локального прокси.
Что доказывает кейс: что на ферме из 30 устройств с UIAutomator2 произошёл массовый каскадный бан в течение 40 минут - это наблюдаемый факт самой команды. Чего кейс не доказывает: что причиной стали именно UIAutomator2-пакеты и совпадение MTU, а не паттерн рассылки, скорость отправки или жалобы получателей. Корреляция замеченных маркеров с баном - не то же самое, что доказанная причинно-следственная связь.
После этого команда переписала логику: ADB циклично отключался после запуска сессии, а пакеты UIAutomator2 переименовывались через рекомпиляцию APK с кастомным Package ID. Это позволило увеличить объём отправки до 80 сообщений с номера в сутки - но это снова наблюдение одной команды, не подтверждённый порог системы.
Ниже - оценки сообщества, не задокументированные Meta пороги.
Все цифры - практический бенчмарк сообщества, не подтверждённые лимиты антифрод-системы - как ориентиры поведенческого антиспама.
«Root через Magisk/Zygisk скроет UIAutomator2» Неверно. UIAutomator2 и ADB не требуют root для базовых кликов, а их маркеры лежат в стандартных слоях ОС - root здесь не помогает и не мешает.
«Wi-Fi ADB вместо проводного решает проблему детекции» Неверно по сути вопроса. Меняется способ передачи команды, но флаг отладки в системных настройках Android остаётся активным независимо от типа подключения.
«Рандомизация пауз убеждает Meta, что это человек» Неполно. Если мессенджер действительно считывает запущенный сервис автоматизации на устройстве, тайминги между сообщениями этот сигнал не маскируют.
«ADB - официальный инструмент, значит за него нельзя забанить» Неверно по логике. Официальность инструмента отладки не означает, что автоматизированное использование платформы соответствует правилам сервиса - это разные плоскости.
Если ферма уже падает каскадом, не чините наугад один параметр - ADB, MTU, пакеты. Сначала зафиксируйте полный профиль поведения сетки на момент бана: скорость отправки, паттерн сообщений, жалобы. Это покажет реальную зону риска лучше, чем любая форумная гипотеза о механизме детекта.
Практическое правило:
То, что Android технически можно прочитать, не значит, что WhatsApp это прочитал и забанил именно за это.