Android studio root права

Rooting the Android Studio AVDs

A quick guide on how to root Android Studio’s Android AVDs (and required files!)

Required files can be found in this repository: https://github.com/0xFireball/root_avd

You need the Android SDK and fresh new AVD. For this guide we will call it RootAVD .

This was written and tested on a Nexus 5X AVD running Android 7.1 Nougat on an Ubuntu Linux host. This method should work with a similar setup (Android Nougat) for the forseeable future, though future Android versions may complicate this process further.

Start emulator $SDK_PATH/emulator/emulator with args -avd RootAVD -writable-system -selinux disabled -qemu -enable-kvm
Wait for boot.
Restart adbd as root and remount system as writable: adb root && adb remount
Install Superuser.apk : adb install SuperSU/common/Superuser.apk
Push su and update permissions: you will have to pick the corresponding architecture $ARCH . adb push SuperSU/$ARCH/su /system/xbin/su , then update permissions: adb shell chmod 0755 /system/xbin/su
Set SELinux Permissive: adb shell setenforce 0
Install SuperSU’s su to system: adb shell su —install
Run SuperSU’s su as daemon. adb shell su —daemon&
Finally, open the SuperSU app on the device, and it will tell you the su binary needs to be updated. Accept and use normal installation.
Installation will fail. Don’t reboot, just move on. It will still work.
Congratulations! You now have a rooted AVD with SuperSU.

TIP: Superuser may not always persist after reboot, to fix:

Источник

Google Play и root права для Android Emulator

Хочу поделиться своим опытом ~~набивания шишек~~ добавления Google Play в эмулятор, входящий в состав Android SDK. Вы спросите: «Да что тут может быть сложного? Добавить нужные .apk и пользоваться с удовольствием, об этом уже писали на Хабре тут!«

А вот и нет, подводных камней оказалось достаточно много. О них я расскажу под катом. Кстати, попутно расскажу как получить root права для эмулятора.

Интересно? Добро пожаловать под кат.

UPD: Обновил устаревшие ссылки.

И так, для начала — чем моя инструкция отличается от написанной ранее? Тем, что при использовании Google Play вы не столкнётесь с такой картиной, когда в категориях видно три с половиной приложения. Например вот, в Top Free видно целых два (sic!) приложения.:

Инструкция написана для ОС Windows, но подойдёт и для других поддерживаемых SDK ОС, просто с маленькими изменениями.

Нам потребуется:
Andoid SDK со следующими установленными пакетами:

Android SDK Tools
Android SDK Platform-tools
SDK Platform для Android 2.3.3
Extras/Android Support
Extras/Google USB Driver

Обладателям процессоров от Intel с поддержкой виртуализации рекомендую, для начала, проследовать инструкции, недавно опубликованной тут, и создать эмулятор с андроидом 2.3.

Создайте папку с именем GooglePlay и откройте консоль в ней. Это легко сделать, кликнув правой кнопкой в папке, с зажатой клавишей Shift. К сожалению это работает только в Windows Vista и выше. Тем, кто пользуется XP, придётся писать пути для cd.

Теперь нужно скачать кое-какие файлы. Сохраняйте все загрузки в созданную папку.
Мы используем эмулятор 2.3, поэтому берём:

Google Apps для CyanogenMod 7
Утилиту mkfs.yaffs2: для ARM эмулятора
Или же mkfs.yaffs2 для x86 эмулятора
SuperUser.apk и su для ARM или x86.

После установки всех пакетов — добавьте android-sdk\tools и android-sdk\platform-tools в системный PATH для удобства работы.

Создайте эмулятор для Android 2.3 с помощью AVD Manager, задав размер SD карты в 200-250 мб.

Запустите эмулятор и когда он полностью загрузится — откройте командую строку и введите команду «adb devices«. Вы должны будете увидеть эмулятор в списке подключённых устройств:

Если его там нет — в эмуляторе заходим в настройки (Кнопка меню — Настройки — Приложения — Разработка). Поставьте галочку на пункте «Отладка по USB» и перезапустите эмулятор. Теперь он должен отображаться в списке.

Далее вас ждёт увлекательный ~~не очень~~ ввод кучи консольных команд и ожидание.

Нам понадобятся файлы GoogleServicesFramework.apk, MarketUpdater.apk и Vending.apk из скачанного архива с GoogleApps. Откройте его и скопируйте их в созданную ранее папку.

Теперь нам нужно сделать несколько хитрых хаков для того чтобы нам были доступны все приложения из Google Play, вне зависимости от их требований. Иначе — вас ожидает картина из нескольких одиноких приложений, как было показано выше. Стоит сделать ремарку — запустить неподдерживаемые приложения не получится, но эти хаки позволят скачать эти приложения на девайс и, после, вытащить apk из эмулятора, например.

Это позволит нам видеть приложения, которые требуют архитектуру процессора ARM7 и поддержку версии версии 2.0.

Так же нам нужен архив с permissions, который можно взять здесь.
Перетащите папку permissions из архива в нашу папку GooglePlay.
Эти файлы нужны для приложений, которые требуют определённое оборудование для работы. Например камеру, или акселерометр.

Кстати, насчёт ввода кучи консольных команд я соврал. Хе-хе.
Вам нужно будет всего лишь создать два .bat файлика. Приступим-с.

Первый файл назовите permissions.bat и наполните его таким вот содержанием:

adb push permissions/android.hardware.camera.autofocus.xml /system/etc/permissions/
adb push permissions/android.hardware.camera.flash-autofocus.xml /system/etc/permissions/
adb push permissions/android.hardware.camera.front.xml /system/etc/permissions/
adb push permissions/android.hardware.camera.xml /system/etc/permissions/
adb push permissions/android.hardware.location.gps.xml /system/etc/permissions/
adb push permissions/android.hardware.location.xml /system/etc/permissions/
adb push permissions/android.hardware.sensor.accelerometer.xml /system/etc/permissions/
adb push permissions/android.hardware.sensor.compass.xml /system/etc/permissions/
adb push permissions/android.hardware.sensor.gyroscope.xml /system/etc/permissions/
adb push permissions/android.hardware.sensor.light.xml /system/etc/permissions/
adb push permissions/android.hardware.sensor.proximity.xml /system/etc/permissions/
adb push permissions/android.hardware.telephony.gsm.xml /system/etc/permissions/
adb push permissions/android.hardware.touchscreen.multitouch.jazzhand.xml /system/etc/permissions/
adb push permissions/android.hardware.touchscreen.multitouch.xml /system/etc/permissions/
adb push permissions/android.hardware.touchscreen.xml /system/etc/permissions/
adb push permissions/android.hardware.wifi.xml /system/etc/permissions/
adb push permissions/android.software.live_wallpaper.xml /system/etc/permissions/
adb push permissions/android.software.sip.voip.xml /system/etc/permissions/
adb push permissions/com.android.location.provider.xml /system/etc/permissions/
adb push permissions/features.xml /system/etc/permissions/
adb push permissions/handheld_core_hardware.xml /system/etc/permissions/
adb push permissions/platform.xml /system/etc/permissions/

После — создайте ещё один, с произвольным названием, например make.bat и таким содержанием:

adb remount
adb push build.prop /system/
adb push su /system/bin/
adb push Superuser.apk /system/app/
adb push Vending.apk /system/app/
adb push MarketUpdater.apk /system/app/
adb push GoogleServicesFramework.apk /system/app/
call permissions.bat
adb push mkfs.yaffs2 /data/misc/
adb shell rm /system/app/SdkSetup.apk
adb remount
adb shell chmod 4755 /system/bin/su
adb shell chmod 777 /data/misc/mkfs.yaffs2
adb shell ./data/misc/mkfs.yaffs2 /system /sdcard/system.img
adb pull /sdcard/system.img system.img

adb push su /system/bin/
adb push mkfs.yaffs2 /data/misc/
adb shell chmod 777 /data/misc/mkfs.yaffs2
adb shell ./data/misc/mkfs.yaffs2 /system /sdcard/system.img

adb push su.x86 /system/bin/su
adb push mkfs.yaffs2.x86 /data/misc/
adb shell chmod 777 /data/misc/mkfs.yaffs2.x86
adb shell ./data/misc/mkfs.yaffs2.x86 /system /sdcard/system.img

В итоге содержимое папки GooglePlay должно быть таким:

Теперь — запускайте файл make.bat и начинайте ждать. Имейте ввиду, что последние две команды из файла make.bat будут выполняться долго. Есть маленькая хитрость — что бы ускорить этот процесс нужно что-нибудь делать на эмуляторе. Например, серфить хабрахабр из эмулятора. Я не знаю как и почему, но когда эмулятор нагружен — это здорово ускоряет процесс создания и копирования system.img.

После того, как консоль отрапортует о выполнении своим закрытием, мы обнаружим в рабочей папке файлик system.img. Теперь закроем эмулятор. Не нужно сразу логиниться или устанавливать какие-то приложения — вы потеряете все изменения после перезапуска эмулятора.

Хватайте появившийся system.img и заменяйте им файлик из папки

Не забудьте сделать резервную копию оригинального system.img!
Обратите внимание, что папка android-10 эквивалента для андроида версии 2.3. Для других версий андроида число после android- равно API Level данной версии.

Теперь заходите в папку, в которой у вас находятся файлы эмулятора и удаляйте файлы «cache.img«, «userdata-qemu.img«, «snapshot.img«, «userdata.img«(если он там есть). По умолчанию для Win7 это

После этого запускайте эмулятор, открывайте Google Play, логиньтесь, принимайте условия соглашения и… перезапускайте эмулятор ещё раз, потому что, зачастую, приложения не хотят загружаться сразу после логина.

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

Надеюсь, моя статья поможет кому-нибудь сохранить время. Спасибо за то, что уделили время на её прочтение.

Источник

Всего лишь меняем модель эмулятора Android устройства

Пролог

Казалось бы, на первый взгляд весьма простая задача. Некоторые читатели могли еще в те бородатые времена лазить по всяким 4пда, рутить свой сенсорный самсунг, менять содержимое файла build.prop и показывать наивным ламерам свой iPhone 15+ Max Pro. Однако, как оказалось, и как оно часто бывает, не все так просто и здесь есть свои подводные камни. Статья призвана помочь простым работягам избежать все кочки да ямы на пути к своей цели!

Дисклеймер

Сразу предупрежу, что люблю писать подобные статьи довольно подробно, не ради объема и многобукав, а ради максимального погружения в проблему и способ ее решения. Обратите внимание, что я работаю на macOS, поэтому все команды в терминале будут ориентированы под данную ОС. Также, следует отметить, что проворачиваю все это для API 30, то есть для самого последнего на момент написания статьи. Как говорят интернеты, сложности по этой теме начались с API 29.

Зачем это нужно?

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

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

Экран не пустивший меня дальше

Достаем build.prop

Как уже говорилось в начале статьи, за имя производителя и модель устройства отвечает системный файл build.prop, который находится в корне устройства в папке system/. Однако при попытке просмотреть его, не говоря уже о редактировании, мы получим отказ в доступе:

Для решения этой проблемы необходимо в терминале обратиться к adb и запросить root права следующей командой: adb root . И вот и первый подводный камень, а именно вывод следующего сообщения: adbd cannot run as root in production builds . Это из-за того что при создании эмулятора мы выбрали вариант с установленными Google сервисами:

Простое решение — создать эмулятор без установленных Google сервисов, после чего повторить команду adb root . После чего в консоли должно появиться сообщение: restarting adbd as root что говорит об успешном проведении операции. Естественно если с самого начала у вас был эмулятор без Google сервисов, то скорее всего с adb root и выше описанной проблемой вы не столкнулись.

Отлично, теперь мы видим содержимое файла build.prop:

Редактируем build.prop

Сохраним файл build.prop в любое удобное место для дальнейшего редактирования выделенной красным области на скриншоте выше. Я сохранил прямо на рабочий стол:

Вносим необходимые изменения. Просмотрев логи запросов и ответов предоставленного мне .apk я нашел приходящий с сервера список разрешенных устройств. То есть, для моих целей нужно поменять два значения на PIXEL 3A XL (как вы поняли, здесь вы можете указывать необходимую именно вам модель):

Сохраняем изменения и заливаем файл обратно на эмулятор. Делается это при помощи команды adb push (кстати, скачать файл с эмулятора можно при помощи adb pull если у вас вдруг аллергия на GUI).

Вводим команду в терминал: adb push build.prop system/

И получаем ошибку:

adb: error: failed to copy ‘build.prop’ to ‘system/build.prop’: remote couldn’t create file: Read-only file system

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

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

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

emulator -avd Pixel3XLAPI30 -writable-system -no-snapshot -nocache

итак здесь Pixel3XLAPI30 — это название нашего эмулятора который мы будем запускать в режиме записи, получить это имя можно выполнив команду emulator -list-avds

-writable-system — собственно тот самый флаг и виновник торжества.

-no-snapshot -nocache — просто советую ввести чтобы избавиться от любого возможного мусора, который может помешать нашему плану-капкану.

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

PANIC: Missing emulator engine program for ‘x86’ CPU.

Что бы и нам решить с этим нужно в файле .bash-profile (или если у вас zsh то в файле .zshenv) находящийся в корне вашего профиля macOS, добавить дополнительные пути. Вот как это выглядит у меня:

есть такая переменная ANDROIDHOME и с ее участием редактируем переменную PATH:

Чтобы изменения вступили в силу перезапускаем терминал (или вводим source

/.bash_profile ) (или source

/.zshenv ). Результат можно проверить выполнив команду echo $PATH и убедиться что в переменной PATH появился добавленный нами путь.

Пробуем запустить эмулятор еще раз.

emulator -avd Pixel3XLAPI30 -writable-system -no-snapshot -nocache

Теперь он должен был успешно запустится.

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

Из описания флага -writable-system:

-writable-system make system & vendor image writable after ‘adb remount’

делаем вывод что теперь нам нужно выполнить adb remount . Для этого открываем новое окно терминала и выполняем сначала команду adb root , что бы adb remount сработало.

После adb remount , будет сообщение что эмулятор нужно перезапустить. Сделать это можно командой adb reboot. Но и здесь не все так просто. Очередной подводный камень об который мы разбили еще один ноготь на пальцах ног. Если сделать adb reboot то все просто напросто зависает НАВСЕГДА. Настолько навсегда, что придется удалять эмулятор и создавать его заново. Интернет и с этим столкнулся и даже баг создали на гуглов. И благо нашлось решение. Чтобы эмулятор не зависал нужно добавить пару команд до adb remount .

Итак по порядку:

Делаем adb root

Теперь делаем adb shell avbctl disable-verification

Если вы вдруг остались в shell то введите exit

Перезагружаем эмулятор adb reboot и ждем

Снова делаем adb root

И вот теперь можно делать adb remount

Ура! Теперь мы можем записывать файлы в системную папку нашего эмулятора. Можем пушнуть наш отредактированный build.prop файл: adb push build.prop system/ . Сделаем adb reboot и убеждаемся что ничего не поменялось… Имя модели не изменилось.

Редактируем правильный build.prop

Вернемся к началу и заметим, что значения ro.product.product.name и ro.product.product.model не соответствует тому, что отображается в настройках устройства. Изучив структуру системных папок я заметил, что существует несколько файлов build.prop, которые располагаются в папках: system, system_ext, vendor и product. Эмпирическим методом я скачивал, редактировал и пушил обратно каждый из этих файлов. В конце концов ключевым оказался файл в папке product. Отредактировав его я наконец-то смог изменить название модели эмулятора устройства!

Подводим итоги

Наконец-то я смогу запустить приложение и воспроизвести баг. Подумал я…

Теперь я уперся в то, что запускаю приложение якобы с рутованого девайса (ну да есть такой грешок). И дело даже не в команде adb root , ведь команда adb unroot не помогла. Что ж, опускать руки уже поздно, придется что-то придумать.

О том, как я обходил проверку на рутованность устройства я расскажу в следующей своей статье. Немного реверс инжиниринга и даже такая популярная библиотека как RootBeer не проблема.

Данной статьей я стремился собрать как можно больше проблем по этому вопросу и изложить все в форме step-by-step. Спасибо за ваше внимание и очень надеюсь, что статья оказалась полезной!

Источник

Android studio root права

Как я могу получить права root через Android SDK?