Всего лишь меняем модель эмулятора 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. Спасибо за ваше внимание и очень надеюсь, что статья оказалась полезной!
Твики build.prop для Android, которые действительно работают
Львиная доля системных параметров Android, скрытых от глаз пользователя, хранится в единственном файле под названием build.prop. Грамотное изменение настроек поможет вдохнуть вторую жизнь в гаджет: улучшить автономность и производительность, оптимизировать интерфейс. В статье мы покажем, как удобно редактировать build.prop, и приведём примеры полезных твиков, а также тех, которые кочуют из статьи в статью на разных ресурсах, но на самом деле не работают.
Что даёт редактирование файла build.prop?
Файл build.prop функционирует следующим образом: при запуске смартфона из него считывается содержимое, тем или иным образом влияющее на логику работы кода операционной системы. Среди таких спрятанных от пользователя настроек есть как глубоко системные, которые лучше не трогать, так и те, которые могут быть безболезненно изменены. Например, добавив несколько строк в build.prop, вы можете ускорить загрузку гаджета, убрать задержку при входящем вызове или включить автоповорот дисплея на экране блокировки. Как это сделать, мы сейчас расскажем.
Как редактировать build.prop?
Всё, что вам потребуется для внесения изменений — редактор текстовых файлов и права суперпользователя. Узнать, как получить root-доступ, можно на нашем форуме в разделе прошивок для Android в теме, посвящённой вашему смартфону или планшету. Для непосредственных изменений в файле можно пользоваться обычным текстовым редактором — для этого придётся самостоятельно найти файл по пути /system/build.prop. Но намного удобнее вносить изменения с помощью специализированной программы, например, BuildProp Editor.
Перед тем как приступить к экспериментам, необходимо обязательно сделать резервную копию файла. BuildProp Editor сохраняет бэкап оригинала автоматически при первом запуске. Если же вы решите пользоваться обычным текстовым редактором, то не забудьте сделать копию вручную. Если что-то вдруг пойдёт не так, то вам будет достаточно заменить «испорченный» build.prop резервной копией, чтобы вернуть всё на свои места.
alt=»Твики build.prop для Android» width=»270″ height=»480″ />
Улучшение интерфейса
Для удобства мы разбили твики на несколько категорий. Первая — улучшение интерфейса. Такие твики наиболее наглядны, поскольку они нередко влияют не только на параметры системы, но и на её внешний вид.
Мгновенный звук вызова. В зависимости от модели смартфона и установленной прошивки при поступлении звонка гаджет может потратить какое-то время на проверку соединения, прежде чем заиграет мелодия. Для пользователя это выглядит следующим образом: сначала у аппарата просто включается дисплей, и только через секунду с небольшим отображается сам звонок. Исправить такое поведение можно внесением в build.prop двух строк:
После перезагрузки аппарата все звонки будут поступать мгновенно.
Автоповорот экрана блокировки. За исключением планшетов, практически ни одно Android-устройство не даёт возможность свободно поворачивать экран блокировки при повороте смартфона. Да, эта функция бывает нужна редко, но если гаджет установлен горизонтально в автомобильном держателе, то попытка ввода пароля или графического ключа превращается в настоящую эквилибристику. Всё, что нужно, чтобы избежать акробатических трюков — дописать в build.prop строки
Что из этого получится — можете увидеть на скриншоте.
Улучшение производительности
К этой категории мы отнесли твики, которые тем или иным образом увеличат скорость работы вашего гаджета.
Ускорение загрузки. Современные смартфоны нередко загружаются едва ли не дольше, чем обычные ПК. Немного поколдовав над настройками в build.prop, можно с лёгкостью увеличить скорость загрузки гаджета в полтора-два раза! В этом помогут следующие настройки:
После внесения этих настроек будет изменён режим выключения гаджета, а также отключена загрузочная анимация разработчика прошивки. В результате при загрузке смартфона вы какое-то время не будете ничего наблюдать на экране. Пугаться этого не стоит: именно благодаря отключению ненужных анимаций тестовый смартфон стал загружаться всего за 30 секунд вместо прежних 50 секунд.
Ускорение работы с памятью. По умолчанию Android логирует множество действий в специальный файл, однако он необходим только разработчикам для дебага приложений. Обычным пользователям этот лог не пригодится, а потому его стоит отключить, добавив в build.prop строку
Отключение лога уменьшит количество дисковых операций, что положительно скажется на быстродействии внутренней памяти смартфона. Правда, разница будет заметна разве что на гаджетах с медленными типами памяти: в нашем случае скорость последовательной записи возросла на 2 МБ/с.
Ускорение сети. Этот твик увеличивает размеры TCP-буферов, что поможет увеличить скорость медленного интернет-соединения, особенно при использовании мобильных сетей. Ну а прописывание DNS-серверов Google в некоторых случаях позволяет снизить время пинга.
net.tcp.buffersize.default=4096,87380,256960,4096, 16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
net.rmnet0.dns1=8.8.8.8
net.rmnet0.dns2=8.8.4.4
net.dns1=8.8.8.8
net.dns2=8.8.4.4
У нас разница оказалась ощутимой, но не стоит забывать, что наибольшее влияние на скорость оказывает постоянно изменяющаяся загрузка базовых станций.
Скорость передачи данных со стандартными настройками
Скорость передачи данных после редактирования build.prop
Увеличение автономности
К сожалению, чудес не бывает — двукратного увеличения автономности достичь не удастся никакими твиками. Но добавить лишние 30-60 минут к времени работы гаджета вполне возможно.
Увеличение интервалов сканирования Wi-Fi. По умолчанию Android сканирует окружающие сети Wi-Fi каждые 20-90 секунд. Причём делает это даже тогда, когда Wi-Fi выключен, но разрешён фоновый поиск сетей для увеличения точности определения местоположения. Чтобы расширить данный интервал, необходимо добавить в файл build.prop строку:
Здесь число 200 и является интервалом сканирования сетей в секундах.
Экономия заряда на LineageOS. Небольшой твик, обеспечивающий более эффективное управление спящим режимом при использовании CyanogenMod или LineageOS на смартфонах с чипсетами Qualcomm:
Ещё больше полезных твиков вы можете найти на форуме 4PDA:
Бесполезные твики, которые ничего не улучшают
Помимо действительно работающих твиков, приведённых в этой статье и в теме на форуме, существует немало таких, которые широко разошлись по Сети, но на самом деле не оказывают никакого влияния на работу системы. Соответствующее исследование провёл один из пользователей ресурса xda. Он проанализировал исходный код AOSP и CyanogenMod и выяснил, что множество популярных твиков просто не упомянуты в исходном коде Android. Среди них есть самые разные записи.
Твики, не экономящие заряд:
ro.ril.disable.power.collapse
ro.mot.eri.losalert.delay
ro.config.hw_fast_dormancy
ro.config.hw_power_saving
Твики, не ускоряющие работу:
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
debug.performance.tuningvideo.accelerate.hw
Другие бесполезные твики. Они предназначены для отключения проверки байт-кода Dalvik и запрета выгрузки лончера из оперативной памяти. Когда-то они действительно работали, но совершенно не актуальны для современных версий Android из-за изменения внутренней архитектуры ОС:
How to Edit build.prop File on Android Devices
If you are into modding your Android smartphone, especially at the root level, you may have come across the file named build.prop found in the /system/ folder. This single file holds the secrets to a ton of customization and changes that can be made in Android. Of course, you will need root access to edit this file because it sits in the system partition. Since the build.prop file contains most of Android’s settings, it also contains the potential for most tweaks and customization. So let’s show you how to edit build.prop first.
Disclaimer
build.prop is a very important file in Android and modifying it is full of risks. Any unwanted change and your device may not get past the boot animation. DroidViews does not take any responsibility in case such a scenario occurs. You must take responsibility for your actions if you decide to proceed. You have already been warned about the risks.
Edit build.prop with a file explorer
To edit the build.prop file, all you need is a text editor and a file browser which can access the root directory. Most of these file browsers come with an inbuilt text editor so if you don’t already have a favorite editor installed, you don’t have to worry about installing one just for editing the build.prop file. Root Explorer, File Explorer Root Browser, and Solid Explorer are some popular file browsers capable of almost anything a file browser can do. In case you have another favorite file browser be sure to let us know about it in the comments.
ES File Explorer Pro is what I use, and that’s what you will find me using in a lot of other tutorials. When you have a root enabled file browser, navigate to the /system/ folder and scroll down to find the build.prop file. Tap on it and choose ES Note Editor or any other editor installed on the device that you wish to use.
Make sure system is mounted as Read/Write.
How to Edit the Android Build.Prop with Essential Tweaks
Android devices use a universal build.prop that controls runtime flags when the Android system boots. Many of the properties are unique to each device, but there are a handful of build.prop tweaks that can be applied universally to virtually all Android phones. This guide will show you these tweaks, and how to edit the build.prop file.
Warning: Tweaking your build.prop can brick your Android device. The tweaks I am sharing should work without problem on any Android device, but you should always have a backup of your data and stock ROM just incase something happens.
How to Edit Your Build.Prop
The fastest method is using a root explorer app (which requires a rooted phone) – ES File Explorer, FX, and Root Explorer are great apps. You will need to mount your /system as read/writable in your root explorer options.
Navigate to your /system folder and find build.prop file, then open it with a text editor.
Alternatively, you can download a build.prop tweaker through Google Play store. BuildProp Editor and ROM Toolbox are recommended apps.
The second method which does not require a rooted phone is through recovery mode. Not all manufacturers’ stock recovery modes allow mounting of /system partition, so if this applies to you, search for how to install a custom recovery such as TWRP on your device.