Смонтировать SD-карту вручную из оболочки adb в android

Я не могу поверить, что никто не ответил Вам в 2 месяца? Круто...как слабину!

ну в любом случае, я полагаю, что должен ввести вас в некоторую информацию, а также задать некоторые вопросы. 1). У вас есть root-доступ или вы вытащили system vold из образа/прошивки выпуска? Как права суперпользователя Linux? 2). Если у вас есть права root access / super user, как вы его получили? Я имею в виду, какой метод вы использовали, чтобы получить корневой доступ? Это было через некоторые скрипты / двоичные файлы и известный эксплойт? Или это было вспыхнул с помощью корневого ядра? Причина, по которой я спрашиваю, заключается в том, что root-доступ-это не просто root-доступ, как считают большинство людей; существуют различные уровни root-доступа. Например, вы можете иметь полный доступ root в качестве пользователя на устройстве, но придет время, когда вы хотите управлять своей системой удаленно сказать из командной строки вашего любимого дистрибутива Linux, то вы можете обнаружить, что корневой доступ не все это трещины до быть. Если вы использовали эксплойт, а не ядро, то, скорее всего, вы только иметь корневой доступ системного уровня, и ADB (Android debug bridge) на ваш компьютер будет сталкиваться с различными сообщениями, такими как "отказано в доступе", "невозможно получить привилегии суперпользователя" или "adb не может работать как root в производственных сборках" или что-то подобное этому. Причина этого заключается в том, что в отличие от некоторых специализированных ядер разработчиков root через эксплойт не делает ядро небезопасным. Я бы рекомендовал вам немного прочитать о том, что такое небезопасное ядро, и если оно подходит для того, что вы надеясь достичь. Почему я говорю это потому, что на некоторых устройствах, имеющих незащищенное ядра не является идеальным, поскольку он может вызвать некоторые нежелательные системные флаги (некоторые постоянные и необратимые по данным некоторых производителей) и используются против разработчиков не соблюдать гарантии или как средство извлечения денег на премиум ремонт устройств (независимо от того, если вы разработчик надеялся сделать некоторый перерыв через открытий...причинил ущерб устройству или нет? который sux). Я думаю, что устройство должно быть в порядке...? Но я не уверен на 100%, поэтому сделайте некоторые исследования.

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

следующее, что вы, вероятно, должны рассмотреть, это то, что вы надеетесь сделать, когда вы получите, где вы хотите в/на устройстве? Ты думал об этом? Если это так, вы можете понять, что стандартный Android консоль / оболочка довольно мрачна и плохо оборудована для инструментов, чтобы делать все великие вещи, которые вы смогли сделать с мгновением Ока на вашем компьютере Linux; это означает, что вам понадобятся некоторые инструменты поддержки, такие как "busybox", а также, возможно, некоторые другие, например, если вы работаете над некоторыми базами данных, которые вы, вероятно, захотите sqlite3, вам, вероятно, понадобится фактический двоичный файл bash для расширения вашей оболочки немного. Вы также хотели бы посмотреть не только на получение этих двоичных файлов, но и на возможно, где они должны быть расположены в вашей системе для удобства доступа в противном случае вы будете получать довольно устали от ввода огромных длинных путей в консоли, чтобы достичь определенных областей вашего устройства, как sdcard. Вы будете знакомы с символическими ссылками, использующими Linux, Ну Android ничем не отличается только тем, что многие системы Android используют контейнер, как среду для приложений. При работе с этим могут быть некоторые препятствия, чтобы преодолеть, как система проверки безопасности на месте попробовать остановить вторжение нежелательных третьих лиц. Это то, что держит большинство разработчиков в безопасности, зная, что их (и ваши) личные данные защищены, однако, когда это вы, и вы хотите войти в эти области устройства, вам нужно правильно настроить свои инструменты. Большинство Android tinkerers используют модифицированный образ восстановления (или пользовательский-не слишком отличается от концепции пользовательского ядра), который позволяет им изменять систему в автономном режиме с помощью в основном простого zip-файла со встроенным обучающий скрипт, двоичный файл и манифест (исследования подписанные и неподписанные молнии для Android пользовательских recoverys - я не буду вдаваться в подробности об этом, но это важно). Вы можете по существу упаковать все свои инструменты в один zip и "flash" установить компоненты в нужные вам области системы и символически связать те же файлы с различными другими местоположениями.

давайте посмотрим на некоторые примеры, скажем, у вас есть root-доступ, потому что вы использовали эксплойт на своем устройство, но защищенное ядро по-прежнему Примечание: защищенное ядро = ro.debugable=0 в вашей системе по умолчанию.Prop файл (создается во время загрузки и не найден или находится в большинстве пакетов прошивки). Если вы хотите разрешить adb иметь корневой доступ, вам нужно будет изменить этот файл и, в частности, строку, о которой я упоминал выше. Могут также быть другие требования, поэтому вы должны посмотреть, что нужно вашему устройству, например, Galaxy Tab, который я ремонтирую на данный момент старше, поэтому использует массовое хранилище вместо протокол передачи мультимедиа, поэтому мне нужно сказать adb, чтобы держать соединение открытым и твердым (Не тайм-аут и разъединение) при работе с устройством; это происходит через значение по умолчанию.файл реквизита также. Трудность возникает, когда вы хотите изменить этот файл; большинство людей декомпилируют ядро и ramdisk и редактируют его напрямую и перекомпилируют, а затем перепрошивают его на устройство в основном потому, что adb, очевидно, не имеет корневого доступа на данный момент. Вы можете вытащить файл из системы, как Итак:

adb pull default.prop default.prop

(это если у вас есть adb на вашем пути среды дистрибутива ПК)

это приведет вас прямо, только проблема в том, когда вы хотите вернуть его после изменения, это может быть довольно сложно. Различные решения о, я слышу много толкая его к SDcard / emmc / storage / sdcard0 / default.prop или / tmp / по умолчанию.prop, а затем требуя вас как "суперпользователя" на устройстве, используя что - то вроде эмулятора терминала, диспетчера сценариев или корневого проводника, чтобы поместить файл вернитесь на место и дайте ему правильные разрешения.

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

adb root
remount

или вы можете обнаружить, что вся ваша консоль не имеет прав суперпользователя, что так когда-либо, поэтому вам потребуется adb shell в оболочку устройства (где у него или у вас есть права суперпользователя) , а затем выполнить команды, которые вы хотите попробовать.

adb shell
su
mount -o rw /system
remount /system

недавно я обнаружил, что вы можете получить тот же уровень доступа через одну строку на консоли adb и один ключ возврата, например:

adb shell su -c mount -o rw,remount /system

это передает аргументы в одной строке adb shell - > Superuser access - > Pass command- > mount as read-write - > remount command - > в системный раздел.

вы можете, если хотите, использовать приведенную выше команду, чтобы получить права суперпользователя от консоли и echo строки по умолчанию.файл prop без необходимости декомпиляции ядра.

в моем случае я просто повторил те же команды несколько раз и переписал по умолчанию.prop с тем же содержанием, только регулируя конкретные переменные по своему вкусу, как это: обратите внимание, что в первой строке используется только 1>, поэтому это эффективно стирает или перезаписывает значение по умолчанию.файл prop, следовательно, остальные строки также должны следовать. Я использую 2 > like >>, потому что это добавляется к следующей строке файл.

adb shell su -c echo ro.secure=1>default.prop
adb shell su -c echo ro.allow.mock.location=0>>default.prop
adb shell su -c echo ro.debuggable=1>>default.prop
adb shell su -c echo persist.sys.usb.config=mass_storage,adb>>default.prop
adb shell su -c echo persist.service.adb.enable=0>>default.prop

это довольно быстро и эффективно для 4 или 5 строк кода, но это не практично, когда вы переписываете большой файл со многими строками теста. Вы можете посмотреть на такие вещи, как grep с циклическими функциями в скрипте bash для фильтрации определенных строк большого файла text/script/config, однако для этого примера и, вероятно, для вашего системного файла vold этого должно быть достаточно.

Я думаю, этого должно быть достаточно, чтобы (извините за каламбур) вооружить вас достаточно информации, чтобы быть опасным :) На этой ноте, пожалуйста, убедитесь, что у вас есть резервная копия вашего устройства, прежде чем вы идете возиться с системой. Они очень похожи на linux, но они также очень разные! Обратите внимание на это предупреждение, убедитесь, что вы сразу создаете резервную копию раздела EFS!! Efs содержит номер IMEI устройства, и это то, что вы действительно не хотите повредить или потерять. Я видел из первых рук, что может произойти; вам даже не нужно вызывать раздел EFS случайно, чтобы сломать он....вам нужно только сделать ошибку, вызывающую явный путь к неправильному разделу, и он может уничтожить ваш IMEI!