I have an android 4.1 phone (Lenovo 820). After some changes aimed at partitioning the internal SD ram (which changed , the phone will no longer mount the external SD card. I am good-ish at Linux, but I have never seen the Android shell before today.
I would love to know the steps to:
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
My /etc/system/vold.fstab has:
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)
I can't believe no one has responded to you in 2 months? Wow...how slack!
Well anyway I spose I should fill you in on some info as well as ask some questions.
1). Have you got root access or did you pull the system vold from a release image/firmware? Like Linux SuperUser rights?
2). If you have root access/super user rights how did you obtain it? I mean what method did you use to gain root access? Was it via some scripts/binaries and a known exploit? Or was it flashed by the means of a rooted kernel?
The reason I ask is that root access isn't just root access as most people are lead to believe; there are varying levels of root access. For instance you may have full root access as a user on the device, but come time when you want to manipulate your system remotely say from command line of your favorite Linux distro then you may find that root access isn't all it's cracked up to be. If you used an exploit and not a kernel then chances are that you only have system level root access, and ADB (android debug bridge) to your PC will be faced with various messages like "access denied", "unable to obtain superuser privileges" or "adb cannot run as root in production builds" or something similar to this.
The reason this happens is because unlike some specialised developer kernels root via an exploit doesn't make the kernel insecure.
I would recommend you do a bit of reading on what an insecure kernel is and if it is suitable for what you are hoping to achieve. The reason I say that is because on some devices having an insecure kernel is not ideal as it can trigger some unwanted system flags (some permanent and irreversible according to some manufacturers) and are used against developers to not honor warranty or as a means of extracting money for premium repair services to devices (regardless of if you the developer hoping to make some break through discoveries...caused the damage to the device or not? which sux). I think your device should be ok...? But I'm not 100% sure so do some research.
If you find that you cannot run an insecure kernel it is not the end of the world, it just requires a little bit more work to get what you want, which I will elaborate with examples in a moment.
Next thing you should probably consider is what you are hoping to do when you get where you want in/on the device? Have you thought that far? If so you may realise that the standard Android console/shell is rather dismal and ill equiped for tools to do all the great things you have been able to do with a blink of an eye on your Linux computer; that means you are going to need some support tools like "busybox" as well as possibly some others as well, like for instance if you are working on some databases you'd probably want sqlite3, you probably need the actual bash binary to extend your shell a bit. You would also want to look at not only just obtaining these binaries but possibly where they should be located on your system for ease of access otherwise you are going to get rather tired of typing huge long paths in the console to reach certain areas of your device like your sdcard. You will be familiar with symlinks having used Linux, well Android is no different only that a lot of the system of Android uses container like environment for applications. When dealing with this there can be some hurdles to overcome as the system has security checks in place to try stop intrusion by unwanted 3rd parties. That is what keeps most developers safe knowing that their (and your) personal data is protected, however when this is you and you want to go in to these areas of the device you need to have your tools setup correctly. Most Android tinkerers use a modified recovery image (or a custom one - not too dissimilar to the custom kernel concept) that allows them to modify the system while it is offline through the means of mostly a simple zip file with embedded instructional script, binary and a manifest (research signed and unsigned zips for Android custom recoverys - I won't go in to detail about that but it is important). You could essentially package up all of your tools into a single zip and "flash" install the components into the areas of the system you require and symlink the same files to various other locations as well.
Lets look at some examples now shall we - say you have root access cause you used an exploit on your device but have secured kernel still note: secured kernel = ro.debugable=0 within your system default.prop file (generated at boot time and not found or located within most firmware packages). If you want to allow adb to have root access you are going to need to change that file and in particular the line I mentioned above. There may also be other requirements so you should look into what your device needs e.g. The Galaxy Tab I am repairing at the moment is older so uses mass storage instead of media transfer protocol, so I need to tell adb to keep the connection open and solid (not time out and disconnect) when engaged with the device; this happens to be done through the default.prop file as well.
The difficulty comes when you want to change this file; most people decompile the kernel and the ramdisk and edit it directly and recompile and then reflash it to the device mainly because adb obviously doesn't have root access at the moment. You can pull the file from the system like so:
adb pull default.prop default.prop
(Thats if you have adb on your PC distro environment path)
This will bring the straight you, only the problem is when you want to put it back after changing it can be rather difficult. Various solutions are about, I hear a lot of pushing it to SDcard /emmc/storage/sdcard0/default.prop or /tmp/default.prop and then requiring you as "SuperUser" on the device using something like terminal emulator, script manager or root explorer to put the file back in place and give it the correct permissions.
typing adb remount on a device with secure kernel will allow you to remount the whole system as read-write and you can do as you please. If insecure though you may end up doing something like
adb root
remount
or you might end up finding that your whole console has no superuser rights what so ever, so you would be required to adb shell into the device shell (where it or you has superuser rights) and then executing the commands you want to try.
adb shell
su
mount -o rw /system
remount /system
I have discovered recently that you can obtain the same level of access through a single line at the adb console and single return key like so:
adb shell su -c mount -o rw,remount /system
This passes the arguments in single string adb shell -> superuser access -> pass command -> mount as read-write -> remount command -> to the system partition.
You could if you like use the above command to gain superuser rights from the console and echo strings into the default.prop file without the need of decompiling the kernel.
In my case I just repeated the same commands a few times and overwrote the default.prop with the same content only adjusting specific variables to my liking like so:
note the first line only uses 1 > so this effectively wipes or overwrites the default.prop file, hence the rest of the lines need to also follow. I use 2 > like >> because this appends to the following line of the 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
This is rather fast and effective for 4 or 5 lines of code, but this is not practical when you are rewriting a large file with many lines of test. You may want to look at things like grep with looping functions in a bash script to filter specific lines of the large text/script/config file, however for this example and probably for your system vold file this should be sufficient.
I think this should be enough to (excuse the pun) ARM you with enough info to be dangerous :)
On that note, please make sure you have got a backup of your device, before you go messing with the system. They are very similar to linux but they are also very different too! Heed this warning, MAKE SURE YOU BACK UP YOUR EFS PARTITION STRAIGHT AWAY!! Efs contains the device IMEI number and this is something you really don't want corrupted or lost. I have seen first hand what can happen; you don't even need to call the EFS partition by accident to break it....you only need make an error calling an explicit path to the incorrect partition and it can obliterate your IMEI!
Related
is there a way to do that? My old phone was rooted and I didn't have any problem getting access to data/data but I bought a Nexus 6 and I cant access to data/data from Android Device Monitor.
All the post I have seen are old and said that I need to root my phone. I know there are a lot of Tutorials on youtube I just dont want to brick my phone, Anyone knows a trusty post so I can root my Nexus 6?
Answer by #THelper
Accessing the files directly on your phone is difficult, but you may be able to copy them to your computer where you can do anything you want with it. Without rooting you have 2 options:
1.If the application is debuggable you can use the run-as command in adb shell
adb shell
run-as com.your.packagename
cp /data/data/com.your.packagename/
2.Alternatively you can use Android's backup function.
adb backup -noapk com.your.packagename
You will now be prompted to 'unlock your device and confirm the backup operation'. It's best NOT to provide a password, otherwise it becomes more difficult to read the data. Just click on 'backup my data'. The resulting 'backup.ab' file on your computer contains all application data in android backup format. Basically it's a compressed tar file. This page explains how you can use OpenSSL's zlib command to uncompress it. You can use the adb restore backup.db command to restore the backup.
I've had a look at other questions but can't seem to find an answer. I'm trying to pull all the files (especially /data) from my android phone but can't seem to due to permission issues.
I am only able to get into download mode and system recovery mode on the phone (a Samsung Galaxy s3) and nothing else (installed a wrong custom rom :( hense the very limited use ). I need to backup all the data before applying a factory reset.
I've tried:
adb root
adb cannot run as root in production builds
adb pull /data ~/Desktop/backupfolder
pull: building file list...
0 files pulled. 0 files skipped.
Also adb shell doesn't allow me to pull (it says device not found even though outside the shell the device is detected). So running su from adb shell is useless if the data can't be pulled. Moving the data doesnt help.
Please help! Apart from download mode and system recovery mode, the phone is dead so solutions requiring apps don't apply.
The most probable cause might be that your phone is not rooted, so you will not be able to remount the partition for read/write access.
There is a particular stack overflow page for remounting a rooted device into RW mode.
link
Remounting is basically reloading your file system so you may read or write into the file system like any other file systems.
You may need to root your phone (please note that rooting will void your warranty).
Rooting lets all user-installed applications run privileged commands typically unavailable to the devices in the stock configuration. Rooting is required for more advanced and potentially dangerous operations including modifying or deleting system files, etc.
In normal production builds root is disabled by default, so you need to install a third party rooting software to get access to this privileged mode.
The entire process of rooting is beyond explanation in this post, but you can check this post from XDA
You need to be very careful while rooting coz it may brickyour phone.
Similar XDA posts are available on google if you search with your exact device name.
I managed to fix the problem!
Downloaded and installed Kies, which also installs the appropriate Samsung drivers. Then ran a firmware installation from there (Tools > Firmware Upgrade and Initialization).
Make sure you have the model number and S/N handy (written on inside of phone).
I am reading a tutorial on the sideload command at link.
It contains the steps of rebooting into recovery mode and using adb sideload [file].zip.
My question is that what does sideload actually do with that zip file ? In the past I have compiled AOSP and flashed a device using
adb reboot-bootloader
adb fastboot flashall -w
Is sideload trying to achieve something similar to the above ?
Edit:
I think my confusion relating to sideload stems from my lack of understanding of how Android's memory is structured. I found two links.
First is a link that explains Android partitions : partitions
Second is a SO answer, that explains Android's memory: memory
Now my understanding so far is this :
Android has RAM and ROM. ROM is divided into several partitions, namely, /system, /data, /boot, /recovery, /cache, /misc and /sdcard.
Now the link relating to sideload states that this command installs a zip file.
What I don't understand still is that, is this zip file, going to replace the entire ROM in Android ? Namely, will it have to have the right partitions as in the list above ?
This also makes me confused about a similar command 'fastboot flashall'. I know when I run it, the terminal goes by saying its writing to several of the partitions. So my questions boil down to these :
1) Is sideload replacing entire ROM ?
2) Is the related command 'fastboot flashall' also replacing entire ROM ?
3) Are there ways to replace select partitions ?
Thanks.
Yes and no. adb reboot-bootloader is used to get yoi into fastboot mode ard sideload is used to apply updates to a system which can be (and is oftenly) used to overwrite a stock OS. I used sideload for exactly that, my fairphone also delivers a small utility to factory reset every partioin of it using adb and sideload (this is the Windows version from scroll down here). Consider chris stratton's comment. You can look into adb backup and adb restore to only deal with user data and apps. Click me tenderly, click me hard. Pay attention as to apps can opt out of this - explanation in this brilliant answer by Izzy.
Depends but more or less yes. fastboot flashall is typically used to flash the recovery partition only to boot from there and continue with sideload (see 1.).
There definitely are, but I'm not able to do it on my own. The referred utility does exactly that. It should be possible to figure out the exact commands or find a similar utility for your manufacturer. I misused mine to flash everything I needed for me. To do so, i just replaced the respcetive .img files such as boot.img
I want to have access to an ext4 partition, without using Data2SD yet, on the SD card of my HTC Vision running the Virtuous Unity 1.3.0 ROM. I modded my /system/etc/vold.fstab file from this:
dev_mount sdcard /mnt/sdcard auto /devices/platform/goldfish_mmc.0
/devices/platform/msm_sdcc.4/mmc_host/mmc2
To this:
#dev_mount sdcard /mnt/sdcard auto /devices/platform/goldfish_mmc.0
/devices/platform/msm_sdcc.4/mmc_host/mmc2
dev_mount sdcard /mnt/sdcard 1 /devices/platform/goldfish_mmc.0 /devices/platform/msm_sdcc.4/mmc_host/mmc2
dev_mount e4vol /mnt/sdcard2 2 /devices/platform/goldfish_mmc.0
/devices/platform/msm_sdcc.4/mmc_host/mmc2
So I can get my second partition, with label e4vol, mount and usable on my Android device. Two issues, and I think one obviously has to do with the other.
I have tried remounting the root read-write and creating the mount point /mnt/sdcard2, but it is gone on reboot. Seems like Android might have in the past created such mounts with mount.conf. Now it does not exist on Gingerbread ROMS. Thoughts?
Is this all I would have to do to get my second partition mounted in Android, or do I also need to create /sdcard2 like /sdcard? I presume both are created as symlinks by vold as specified in this conf file, but I have not had time to check yet.
I would ask forums, but this seems like a developer question and this is the most recent release of the OS. It seems to change a lot from version to version of the OS. Thanks in advance for your patience and help.
UPDATE: So, moved the test mount to sdcard, and it did not work, even with a persistent mount point. So, not sure where I am going wrong.
Maybe you'll have to have a look into /init.rc.
There are some "mkdir /mnt/..."-statements. You only have to add your "mkdir /mnt/sdcard2" and "ln -s /mnt/sdcard2 /sdcard2" to this file.
But be careful when editing this file!!!
I looked at the vold source up to including Icecream-Sandwich: it’s final mount() system call is hardcoded to the “vfat” file system type. – Even if you get it to try the mount, it would fail.
I myself actually want to mount my ext4 SD card to /sdcard, because I regularly suffer from SD card FAT file system corruptions (and I’m not the only one having those with Android).
The alternative is: modify the init/boot process to just mount the partition where you want, bypassing vold.
When I build the Android sources, I end up with 3 images. They are ramdisk.img, system.img and userdata.img.
I'm trying to understand what these are made of and how they are used by Android. I came across articles which say "/system" is a yaffs2 file system.
1) If I want to make use of this on a real board, should the file system be yaffs2 or can it be any?
2) If I want to get the 3 images for another file system(say ext2), how do I do that?
You can modify the kernel to accept basically any filesystem you want (ext2 and ext4 are two examples), if you can make it compile. Then, it's just a matter of mounting and formatting the volume with the corresponding filesystem.
There are patches for different kernels in github and xda-developers. You will need to browse around to find the patch for your particular device. Unfortunately this is not something you can sole for all devices with a single hack.