Montare una scheda SD manualmente dalla shell adb in Android

? Merc @ | Original: StackOverFlow
---

Ho un Android 4.1 telefono ( Lenovo 820 ) . Dopo alcune modifiche volte a compartimentare l'ariete SD interna ( che ha cambiato, il telefono non sarà più il supporto della scheda SD esterna . Sono bravo -ish a Linux, ma non ho mai visto la shell di Android prima di oggi .

Mi piacerebbe conoscere la procedura per :

Get the list of available devices representing SD cards Manually mount the SD card -- the mount command won't work as it says can't read /etc/fstab -- how do you mount things? Get the SDcard to mount at boot time

La mia /etc/system/vold.fstab ha :

dev_mount sdcard /storage/sdcard0 emmc@fat /devices/platform/goldfish_mmc.0 /devices/platform/mtk-msdc.0/mmc_host
dev_mount sdcard2 /storage/sdcard1 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-msdc.1/mmc_host

Mount is now:

rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/secure type tmpfs (rw,relatime,mode=700)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/emmc@android on /system type ext4 (ro,relatime,nobarrier,noauto_da_alloc,commit=1)
/emmc@usrdata on /data type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@cache on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@protect_f on /protect_f type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
/emmc@protect_s on /protect_s type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
---

Top 5 Risposta

1Jarmez @

Non posso credere che nessuno ha risposto a voi in 2 mesi ? Wow ... come slack !

Se si scopre che non è possibile eseguire un kernel insicuro non è la fine del mondo, che richiede solo un po 'più di lavoro per ottenere ciò che si vuole, che mi dilungherò con esempi in un attimo .

Vediamo alcuni esempi ora dobbiamo - dire di avere accesso root causa si è utilizzato un exploit sul dispositivo, ma hanno assicurato kernel ancora notare : kernel assicurato = ro.debugable=0 all'interno del file system default.prop ( generato in fase di avvio e non trovato o situati all'interno della maggior parte dei pacchetti firmware ) . Se si desidera consentire adb di avere accesso root che si sta per bisogno di cambiare il file e in particolare la linea che ho citato sopra . Ci possono essere anche altri requisiti così si dovrebbe guardare in quanto il dispositivo ha bisogno per esempio Il Galaxy Tab Sto riparando al momento è vecchio e quindi utilizza l'archiviazione di massa, invece di Media Transfer Protocol, quindi ho bisogno di dire adb per mantenere la connessione aperta e solida ( non timeout e disconnessione ) quando è impegnato con il dispositivo ; questo accade per essere fatto attraverso il file default.prop pure . La difficoltà arriva quando si desidera modificare questo file ; la maggior parte delle persone decompilare il kernel e il ramdisk e modificare direttamente e ricompilare e poi reflash al dispositivo soprattutto perché adb ovviamente non ha accesso di root al momento . Si può tirare il file dal sistema in questo modo:

adb pull default.prop default.prop

( Quello è se avete ADB sul vostro percorso dell'ambiente distro PC)

Questo porterà il diritto voi, solo il problema è quando si vuole mettere di nuovo dopo la modifica può essere piuttosto difficile . Varie soluzioni sono circa, ho sentito un sacco di spingere a SDcard /emmc/storage/sdcard0/default.prop o /tmp/default.prop e quindi si richiede come " SuperUser " sul dispositivo usando qualcosa come emulatore di terminale, script manager o root explorer per mettere il file al suo posto e dare le autorizzazioni corrette .

digitando remount adb su un dispositivo con kernel sicuro vi permetterà di rimontare l'intero sistema in lettura -scrittura e si può fare come ti pare . Se insicuro se si può finire per fare qualcosa di simile

adb root
remount

o si potrebbe finire per trovare che tutto il tuo console non ha diritti di superutente cosa così mai, così si sarebbero tenuti a adb shell nella shell dispositivo ( dove o si disponga di diritti di super utente ) e quindi eseguire i comandi che si desidera provare .

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

Ho scoperto di recente che è possibile ottenere lo stesso livello di accesso attraverso una singola linea alla console adb e solo tasto di ritorno in questo modo:

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

Questo passa gli argomenti in un'unica stringa adb shell - > Accesso superuser - > comando PASS - > montare come lettura-scrittura - > Comando rimontare - > per la partizione di sistema .

Si potrebbe, se volete usare il comando di cui sopra per ottenere i diritti di superuser dalla console e stringhe eco nel file default.prop senza il bisogno di decompilazione del kernel .

Nel mio caso ho solo ripetuto gli stessi comandi un paio di volte e sovrascritto il default.prop con lo stesso contenuto unico di regolazione variabili specifiche di mio gradimento in questo modo: notare la prima linea utilizza solo 1 > quindi questo asciuga efficacemente o sovrascrive il file default.prop, quindi il resto delle linee devono seguire anche . Io uso 2 > >> così perché questo aggiunge la seguente riga del file .

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

Questo è piuttosto rapido ed efficace per 4 o 5 linee di codice, ma questo non è pratico quando si riscrivendo un file di grandi dimensioni con molte linee di prova. Si consiglia di guardare le cose come grep con le funzioni loop in uno script bash per filtrare specifiche linee di grandi file di testo / script / config, ma per questo esempio e, probabilmente, per il file system vold questo dovrebbe essere sufficiente .

Penso che questo dovrebbe essere sufficiente per ( scusate il gioco di parole) si braccio abbastanza informazioni per essere pericoloso :) In tal senso, si prega di assicurarsi di aver ottenuto una copia di backup del dispositivo, prima di andare scherzi con il sistema . Essi sono molto simili a Linux, ma sono anche molto diverse anche! Prestare attenzione a questo avviso, FATE IL BACKUP DEI EFS PARTITION SUBITO !! Efs contiene il numero IMEI del dispositivo e questo è qualcosa che davvero non si vuole danneggiato o perso . Ho visto in prima persona che cosa può accadere ; non hanno nemmeno bisogno di chiamare la partizione EFS per caso a rompere .... basta fare un errore di chiamare un percorso esplicito alla partizione errata e può cancellare la tua IMEI !