Build prop ошибка сохранения

Пролог

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

Дисклеймер

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

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

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

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

Как уже говорилось в начале статьи, за имя производителя и модель устройства отвечает системный файл 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, добавить дополнительные пути. Вот как это выглядит у меня:

export ANDROIDHOME=~/Library/Android/sdk

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

export PATH=$ANDROIDHOME/emulator:$ANDROIDHOME/tools:$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. 

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

1. Делаем adb root

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

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

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

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

6. И вот теперь можно делать 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. Спасибо за ваше внимание и очень надеюсь, что статья оказалась полезной!

^{Summing up the solution from above comments:}

Fixing up the possibly broken build.prop file

You don’t need to mount your SDCard to revert your changes. If you can boot into recovery, and access the device via adb shell, you can do so and replace your edited build.prop file with the backup copy you’ve created (using the cp command), thus restoring the state of before your edit. Example, assuming you’ve named your backup build.prop.bak and placed it in the same place as the original:

# re-mount /system read/write
adb remount
# copy back the original file
cp /system/build.prop.bak /system/build.prop
# as bassmadrigal pointed out: let's make sure the file permissions are fine
chmod 644 /system/build.prop
# reboot the device
adb reboot

Keep in mind the file ends with «prop», which is short-hand for «properties» — not «prob» as short-hand for «probabilities

If it still not boots: uninstall the last app installed

As the first part didn’t solve the problem here, it might be the app installed (facebook home in our case) is causing trouble on the device it was not intended for. So let’s kick it out. Boot into recovery again, get your ADB ready, and

# uninstall the app
# adb shell pm uninstall <package_name>
adb shell pm uninstall com.facebook.home
# reboot the device
adb reboot

This finally solved it.

As a factory-reset was done, how was the app able to survive that?

This was an after-thought to the entire issue. A possible explanation lies in the fact that the factory-reset complained about the SDCard not being able to mount. So if parts of the app got installed to the card, they might have survived there. Unlikely as this is (after all, apps on SDCard should not be able to cause boot issues, as the card is mounted only after boot_completed), I see no other explanation (comments welcome, I can include them here if wished for).

This lead to another question:

Should I remove the external SD card to protect it from factory reset?

Normally, a factory reset should not touch the external SDCard. But «better safe than sorry»: if it should not be touched normally, it shouldn’t matter whether it’s in the device or not, so it shouldn’t hurt to remove it before the factory reset. However: if you use(d) app2sd, there’s a special directory called .android_secure on the SDCard holding the (encrypted) parts of the «moved apps». After a factory reset. the system does not know of them — so when re-installing such an app, it might lead to problems. Thus when removing the card before doing a factory reset, make sure to remove the .android_secure directory from the card (using a card reader and your computer) before re-inserting it again.

^{Summing up the solution from above comments:}

Fixing up the possibly broken build.prop file

You don’t need to mount your SDCard to revert your changes. If you can boot into recovery, and access the device via adb shell, you can do so and replace your edited build.prop file with the backup copy you’ve created (using the cp command), thus restoring the state of before your edit. Example, assuming you’ve named your backup build.prop.bak and placed it in the same place as the original:

# re-mount /system read/write
adb remount
# copy back the original file
cp /system/build.prop.bak /system/build.prop
# as bassmadrigal pointed out: let's make sure the file permissions are fine
chmod 644 /system/build.prop
# reboot the device
adb reboot

Keep in mind the file ends with «prop», which is short-hand for «properties» — not «prob» as short-hand for «probabilities

If it still not boots: uninstall the last app installed

As the first part didn’t solve the problem here, it might be the app installed (facebook home in our case) is causing trouble on the device it was not intended for. So let’s kick it out. Boot into recovery again, get your ADB ready, and

# uninstall the app
# adb shell pm uninstall <package_name>
adb shell pm uninstall com.facebook.home
# reboot the device
adb reboot

This finally solved it.

As a factory-reset was done, how was the app able to survive that?

This was an after-thought to the entire issue. A possible explanation lies in the fact that the factory-reset complained about the SDCard not being able to mount. So if parts of the app got installed to the card, they might have survived there. Unlikely as this is (after all, apps on SDCard should not be able to cause boot issues, as the card is mounted only after boot_completed), I see no other explanation (comments welcome, I can include them here if wished for).

This lead to another question:

Should I remove the external SD card to protect it from factory reset?

Normally, a factory reset should not touch the external SDCard. But «better safe than sorry»: if it should not be touched normally, it shouldn’t matter whether it’s in the device or not, so it shouldn’t hurt to remove it before the factory reset. However: if you use(d) app2sd, there’s a special directory called .android_secure on the SDCard holding the (encrypted) parts of the «moved apps». After a factory reset. the system does not know of them — so when re-installing such an app, it might lead to problems. Thus when removing the card before doing a factory reset, make sure to remove the .android_secure directory from the card (using a card reader and your computer) before re-inserting it again.

Слово автора:
Это статья написана мной, т.е.

Papa Roach

, с использованием

этих материалов

, которая не претендует на универсальность и открытие «Америки».Скорее она предназначена для ознакомления и в качестве деления личным опытом и размышлениями, ну и чутку для науки))))

Введение:
В файловой системе любого смартфона на Android есть файл

build.prop

, который лежит по пути

/system/build.prop

.Само собой для доступа к этому файлу нам нужны

root-права

!
В данном файле хранятся данные о прошивке и настройки смартфона, которые применяются после включения аппарата.
Ниже я приведу твики, которые позволяют немного улучшить производительность нашего гуглофона, ну или по крайней мере сделать его работу более «комфортной».
Предупреждаю!Все вы делаете на свой страх и риск!За работоспособность твиков не ручаюсь ибо каждый аппарат индивидуален. Я проверял на своем Acer E400(Android 2.1)

Модернизация:
Для начала делаем бекап и другие действия для сохранения нервов в случае неудачного редактирования файла!!!
Далее открываем файл и начинаем его редактирование.Если описанных ниже строчек нет в вашем файле, то просто пишите их в конец файла.
Поехали(вместо звездочки * пишем нужное нам значение):
1)debug.sf.hw=*. Эта строчка отвечает за Аппаратное ускорение. Оно нужно для ускорения графического интерфейса. Значение 1 его активирует. Значение 0 его выключает.Пробуйте, проверяйте и вам воздастся.Лично у меня возникает рябь в графике(

возможно сильная!

), поэтому оффнул его.

2)wifi.supplicant_scan_interval=***. Эта строчка отвечает за интервал поиска Wi-Fi сетей. По умолчанию стоит 20. Значение измеряется в секундах. Это означает, что у нас стоит 20 сек. Советуется для экономии батареи поставить значение 180-200.

3)pm.sleep_mode=1
ro.ril.disable.power.collapse=0 –иностранные коллеги также советуют прописать эти 2 строчки для экономии заряда батареи.

4)dalvik.vm.heapsize=*m. Эта строчка устанавливает значение heapsize. Смысл в том, что в большинстве прошивок установлено малое значение памяти для использования приложением, программа расширяет это значение, тем самым увеличивая производительность и делая устройство более стабильным.
Большое значение лучше не ставить, хотя можно поэкспериментировать.
Лучший вариант — это 32m. Его кстати и рекомендуют.

5)dalvik.vm.execution-mode=int:***. Эта строчка отвечает за JIT. Значение

jit

включает его, а значение

fast

выключает.Технология JIT также служит для увеличения производительности аппарата.Еще раз напомню-может работать не у всех.

6)windowsmgr.max_events_per_sec=60. Делает интерфейс более гибким и плавным. Этой строчки изначально нет, нужно дописывать самому.Можете поиграться со значениями и выбрать подходящее.

7)ro.media.enc.jpeg.quality=100-повышаем качество jpg.А если быть более точным, то изменяем степень сжатия фоток.При параметре 100 размер фоток вырастет примерно в 2 раза.

ro.media.dec.jpeg.memcap=8000000
ro.media.enc.hprof.vid.bps=8000000 – повышаем качество аудио- и видеозаписи камеры.Опять же-выше заложенных аппаратных возможностей не прыгнешь, но зато достигнешь потолка)

9)debug.sf.nobootanimation=1 – отключаем анимацию при включении.Немного ускоряет включение аппарата.

10)
ro.lge.proximity.delay=25
mot.proximity.delay=25 – отключает появляющееся черное окошко после окончания звонка.Меня реально раздражало и это лично мне помогло)))

11)
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 – меняем размер буфера TCP-говоря проще, немного улучшаем интернет-соединение.Будет полезным для тех, у кого медленный инет.

12)
ro.ril.hsxpa=2
ro.ril.gprsclass=10
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=10
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=5 –твики для улучшения приема 3G-сигнала.Сам не проверял-оставляю на вас.

13)ro.HOME_APP_ADJ=1 — запрет на выгрузку лаунчера из памяти.

14)ro.kernel.android.checkjni=0 — исправляет некоторые ошибки приложений.

15)persist.adb.notify=0 — отключение иконки режима отладки в статусбаре.

16)ro.config.hw_menu_unlockscreen=false — для включения возможности разблокирования экрана при помощи кнопки «Меню» (двойного нажатия), измените значение с «false» на «true»

17)Точное предназначение следующих строчек я не знаю, поэтому просто приведу список.Те, кто знает что они делают лучше прошу отписаться мне:

persist.sys.use_dithering=0
persist.sys.purgeable_assets=1
dalvik.vm.dexopt-flags=m=y
ro.mot.eri.losalert.delay=1000

18) Твики, определенные только для телефонов LG!

persist.service.pcsync.enable=0
persist.service.lgospd.enable=0
user.feature.flex=true
user.feature.lgdrm=false
user.feature.lgresource=false
user.feature.lgpoweroff=false
user.feature.ls_event=false
user.feature.ls_normal=false
user.feature.sui=false

p.s.Надеюсь кому-то будет полезным, но замечу, что если у вас стоит кастомная прошивка, то скорее всего многие твики уже включены в прошивке!

p.p.s.В прикрепленных файлах скрины файла builp.prop-на всякий случай

p.p.p.s. Спасибо за инфу

Asat-777

,

n81bla

и

dvortep
Дополнительный скрин #1

(39, 83 Kb)

Дополнительный скрин #2

(28, 39 Kb)

На чтение 4 мин. Просмотров 446 Опубликовано 16.04.2021