Мое приложение имеет определенную функциональность, которая будет работать только на устройстве, где доступен root. Вместо того, чтобы эта функция не работала при ее использовании (и затем показывать соответствующее сообщение об ошибке пользователю), я бы предпочел возможность молча проверять, доступен ли сначала root, и, если нет, сначала скрывать соответствующие параметры. ,
Есть ли способ сделать это?
Ответы:
Вот класс, который будет проверять Root одним из трех способов.
источник
su
бинарный файл, но без рута.Если вы уже используете Fabric / Firebase Crashlytics, вы можете позвонить
Это текущая реализация этого метода:
источник
Библиотека RootTools предлагает простые методы для проверки на наличие root:
Ссылка
источник
В моем приложении я проверял, является ли устройство рутованным или нет, выполнив команду «su». Но сегодня я удалил эту часть своего кода. Зачем?
Потому что мое приложение стало убийцей памяти. Как? Позвольте мне рассказать вам мою историю.
Были некоторые жалобы, что мое приложение замедляло работу устройств (конечно, я думал, что это не может быть правдой). Я пытался выяснить, почему. Поэтому я использовал MAT, чтобы получить кучу дампов и проанализировать, и все казалось идеальным. Но после многократного перезапуска приложения я понял, что устройство действительно работает медленнее, и остановка моего приложения не делала его быстрее (если я не перезагружаю устройство). Я снова проанализировал файлы дампа, пока устройство работает очень медленно. Но все было идеально для файла дампа. Тогда я сделал то, что должно быть сделано сначала. Я перечислил процессы.
SURPRIZE; для моего приложения было много процессов (с меткой процесса моего приложения в manifest). Некоторые из них были зомби, некоторые нет.
С примером приложения, которое имеет одну активность и выполняет только команду su, я понял, что процесс зомби создается при каждом запуске приложения. Сначала эти зомби выделяют 0 КБ, но потом что-то происходит, и процессы зомби держат почти те же КБ, что и основной процесс моего приложения, и они стали стандартными процессами.
На bugs.sun.com есть отчет об ошибке для той же проблемы: http://bugs.sun.com/view_bug.do?bug_id=6474073 это объясняет, если команда не найдена, зомби будут созданы методом exec () , Но я до сих пор не понимаю, почему и как они могут стать стандартными процессами и иметь значительные КБ. (Это не происходит все время)
Вы можете попробовать, если хотите, с примером кода ниже;
Простой метод выполнения команд;
Подводить итоги; Я не советую вам определять, является ли устройство рутованным или нет. Но на вашем месте я бы не использовал Runtime.getRuntime (). Exec ().
Кстати; RootTools.isRootAvailable () вызывает ту же проблему.
источник
Многие из перечисленных здесь ответов имеют присущие проблемы:
Библиотека RootTools от Stericson, кажется, проверяет root более законно. Он также имеет много дополнительных инструментов и утилит, поэтому я очень рекомендую его. Тем не менее, нет объяснения того, как именно он проверяет наличие root, и он может быть немного тяжелее, чем нужно большинству приложений.
Я сделал несколько служебных методов, которые свободно основаны на библиотеке RootTools. Если вы просто хотите проверить, находится ли исполняемый файл "su" на устройстве, вы можете использовать следующий метод:
Этот метод просто просматривает каталоги, перечисленные в переменной окружения «PATH», и проверяет, существует ли файл «su» в одном из них.
Для того, чтобы действительно проверить наличие root-прав, команда su должна быть действительно запущена. Если приложение, такое как SuperUser, установлено, то в этот момент оно может запросить root-доступ или, если оно уже было предоставлено / отклонено, может быть показан тост, указывающий, был ли предоставлен или запрещен доступ. Хорошая команда для запуска - это «id», чтобы вы могли убедиться, что идентификатор пользователя на самом деле равен 0 (root).
Вот пример метода, чтобы определить, был ли предоставлен root-доступ:
На самом деле важно протестировать выполнение команды "su", потому что в некоторых эмуляторах предварительно установлен исполняемый файл "su", но доступ к нему разрешен только определенным пользователям, например оболочке adb.
Также важно проверить наличие исполняемого файла "su" перед тем, как запускать его, поскольку известно, что android неправильно распоряжается процессами, которые пытаются запустить отсутствующие команды. Эти побочные процессы могут увеличивать потребление памяти с течением времени.
источник
Обновление 2017
Вы можете сделать это сейчас с Google Safetynet API . API SafetyNet предоставляет API-интерфейс аттестации, который помогает оценить безопасность и совместимость сред Android, в которых работают ваши приложения.
Эта аттестация может помочь определить, было ли конкретное устройство подделано или иным образом модифицировано.
Аттестационный API возвращает ответ JWS, подобный этому
Анализ этого ответа может помочь вам определить, является ли устройство рутованным или нет
Вы можете сделать это на стороне клиента, но рекомендуется проанализировать ответ на стороне сервера. Базовая архитектура клиент-сервер с API защитной сети будет выглядеть так:
источник
Корневая проверка на уровне Java не является безопасным решением. Если ваше приложение имеет проблемы с безопасностью для запуска на устройстве с корнем, пожалуйста, используйте это решение.
Ответ Кевина работает, если только в телефоне нет приложения вроде RootCloak. Такие приложения имеют API-интерфейсы Handle over Java после рутирования телефона, и они высмеивают эти API, чтобы вернуть телефон без рута.
Я написал код нативного уровня, основанный на ответе Кевина, он работает даже с RootCloak! Также это не вызывает проблем с утечкой памяти.
В вашем Java-коде вам нужно создать класс-оболочку RootUtils для собственных вызовов
источник
http://code.google.com/p/roottools/
Если вы не хотите использовать файл JAR, просто используйте код:
Программа попытается найти папку su:
Пример:
источник
checkRootMethod4()
с Ответом Кевина .== true
в логическое значение, оно ничего не добавляет и выглядит не очень хорошо.if (isRooted())
проверь вместо явного написания true. Лучше следовать шаблонам написания кодаВместо использования isRootAvailable () вы можете использовать isAccessGiven (). Прямо из RootTools вики :
Ссылка
источник
Некоторые модифицированные сборки используются для установки системного свойства
ro.modversion
для этой цели. Вещи, кажется, пошли дальше; моя сборка от TheDude несколько месяцев назад имеет следующее:С другой стороны, эмулятор из SDK 1.5, на котором работает образ 1.5, также имеет root, вероятно, похож на Android Dev Phone 1 (который вы, вероятно, хотите разрешить) и имеет следующее:
Что касается розничных сборок, у меня их нет, но различные поисковые запросы
site:xda-developers.com
носят информативный характер. Вот G1 в Нидерландах , вы можете увидеть, чтоro.build.tags
не имеетtest-keys
, и я думаю, что это, вероятно, самое надежное свойство для использования.источник
RootBeer - это библиотека Android, проверяющая root, созданная Скоттом и Мэтью. Он использует различные проверки, чтобы указать, является ли устройство рутованным или нет.
источник
Я предлагаю использовать нативный код для обнаружения рутов. Вот полный рабочий пример .
Обертка JAVA :
Оболочка JNI (native-lib.c) :
константы:
обнаружения корня из нативного кода:
источник
Вот мой код, основанный на некоторых ответах здесь:
источник
В дополнение к ответу @Kevins, я недавно обнаружил при использовании его системы, что Nexus 7.1 возвращался
false
для всех трех методов - Нетwhich
команды, нетtest-keys
иSuperSU
не был установлен в/system/app
.Я добавил это:
Это немного менее полезно в некоторых ситуациях (если вам нужен гарантированный root-доступ), поскольку вполне возможно, что SuperSU будет установлен на устройствах, которые не имеют доступа SU.
Однако, поскольку SuperSU может быть установлен и работать, но не в
/system/app
каталоге, этот дополнительный случай вычеркнет (ха-ха) такие случаи.источник
источник
Две дополнительные идеи, если вы хотите проверить, поддерживает ли ваше устройство права root в вашем приложении:
Runtime.getRuntime().exec()
/system/app/Superuser.apk
местоположенииисточник
Использование C ++ с ndk - лучший подход для обнаружения root, даже если пользователь использует приложения, скрывающие его root, такие как RootCloak. Я протестировал этот код с помощью RootCloak и смог обнаружить рут, даже если пользователь пытается его скрыть. Итак, ваш файл cpp хотел бы:
И вы будете вызывать функцию из вашего кода Java следующим образом
источник
источник
Существует Safety Net Аттестационная API из услуг в Google Play , с помощью которого мы можем оценить устройство и определить , если она коренится / подделана.
Пожалуйста, пройдите мой ответ, чтобы разобраться с рутированными устройствами:
https://stackoverflow.com/a/58304556/3908895
источник
Забудьте все, что обнаруживает корневые приложения и su-файлы. Проверьте процесс корневого демона. Это можно сделать из терминала, и вы можете запускать команды терминала в приложении. Попробуйте эту однострочную.
Для этого вам также не нужно разрешение root.
источник
Действительно, это интересный вопрос, и пока никто не заслужил награду. Я использую следующий код:
Код, конечно, не пуленепробиваемый, потому что сеть может быть недоступна, поэтому вы получите исключение. Если этот метод возвращает true, тогда вы можете быть уверены, что 99%, иначе только 50%, что нет. Сетевое разрешение также может испортить решение.
источник
Используя мою библиотеку в rootbox , это довольно просто. Проверьте необходимый код ниже:
источник