We have several devices running Android in an industrial environment.
We think about completely setting up one device and then copy the whole /data directory to the other devices. The expected benefit is to configure things like wireless settings and install the required apps and updates only once on one device and somehow bring this onto the other devices.
Is this a good idea?
I am not sure if there is device specific information stored in data such as a device ID or something else that we would mess up with our idea.
Besides this what about 'uid's that are responsible to represent app permissions? Do you expect problems if our apps are not installed onto a device but simply come by a copied /data partition?
Is something specific established on a device after the first boot when /data is created and filled, that should not be replaced with something else?
Would it be better to copy only selected directories or even files? This is much more effort but ok if there is no other way...
I would appreciate any input about what can go wrong and what we should consider.
Related
I would like to retrieve files/folders(directories) in Android (on a smartphone)
and I can only do it thru the recovery mode, bootloader, etc, where I can see ONLY all the folders (e.g. Downloads, DCIM, ...), but naturally can not see the files in those folders. How do I go about getting those files off (say in ADB sideload?, or whatever tools are available for that purpose. I can connect the phone via usb and do it on Win10 (Linux or other platforms are also a possibility.) For some reason, I think this is highly technical, but I could be wrong. I hope someone knows.
I can post further info, perhaps pics of what I see, if needed. After retrieving the files/folders, I can reset
the phone.
Thanks to all!
joe
I tried to see if I can do it in ADB, but no luck.
The title pretty much covers my question. I want to connect a USB-Stick to an Android powered tablet (OTG cable).
In my app i want to provide an option to copy a txt-file from a specific folder on my tablet to the connected USB-Stick. This option should also check, if there already is a txt-file on the Stick (not the exact same filename, just similar) and delete that file, so i only have exactly 1 file (txt-file) on that USB-Stick.
I can imagine, deleting stuff on a USB-Stick isn't supported at all since it creates security issues, but if the copying was possible, that already would be great.
Thanks in advance :)
I've been trying to write a small program to copy a folder on my mac (10.10.3), containing a set of songs, into the music folder on my Galaxy S3 (GS3) when it is connected via USB. Clearly I could just use Android File Transfer (AFT), and copy the files in (manually), however this wouldn't teach me anything. My goal is thus to automate this act. Python seems like a good choice for this project, as it seems like mostly scripting (in fact a Bash script may suffice).
This should be simple, using a bash script like cp ~/../music_on_mac /.../music_target_on_android
However, the file structure of the GS3 doesn't show up in the finder (like you would expect from an ordinary USB drive). I can only see the file structure via Android File Transfer. From what I've read, this is expected behavior (I suppose due to formatting differences?). Thus I've been unable to find the target directory /.../music_target_on_android
My best guess (getting a bit out of my depth here), is that I need to copy the music folder, and then pipe it to AFT, and have AFT place it in/on top of the target Music folder on my GS3. Is this correct? If so, could anyone offer suggestions on implementing this? If not, alternative approaches or suggestions would also be appreciated.
I'd also note that I considered using ./adb push <local> <remote> to try to copy the files directly, however this pushed back that the device was read only. I'm also not familiar enough to find the proper directory on the GS3 (the one containing the target for the "Music" folder) using ./adb shell. There's also the added downside that in order to use a solution involving the ADT, one must have the ADT (which most people don't). Moreover, I want to keep it simple.
Research Update:
I've found that my phone will not show up in Finder because Google has disabled USB mass storage (aka mounting the phone as a disk) in favor of the Media Transfer Protocol (MTP). AFT is just an MTP client, needed because unlike Windows and Linux, OSX does not support MTP.
http://www.howtogeek.com/192732/android-usb-connections-explained-mtp-ptp-and-usb-mass-storage/
Based on tips, I've been able to implement an alternative based on creating an FTP server on my phone. Connecting to this gives me file system access and write privileges from my terminal, which is half the battle, however its quite slow. Thus I'd still like to find a way to automate instructions to Android File Transfer.
Yesterday I decided to fix the internal front speakers of my "HTC Desire Z" (aka. G2). While I was able to fix them, I broke the connector for the microSD slot (the left one). After trying to fix it for several hours, I gave up. It isn't in the scope of my hardwareskills :-(
Well, since I have like 600mb left on /data and my device is rooted, I tried to find a software solution i.e. "emulate" a SDcard device (because many applications require one to work properly, e.g. the camera app). I found here http://www.android-x86.org/documents/sdcardhowto a description how to create a vfat image and mount it as loopback.
While this is exactly what I want, I don't get it to work:
I don't know how to modifiy /proc/cmdline, or
how the entry in /etc/vold.fstab should look like.
dev_mount sdcard /mnt/sdcard auto /data/sdcard.img
didn't work for me. according to logcat, I have this version: I/Vold ( 2368): Vold 2.1 (the revenge) firing up
btw, just mounting the loopback device to /mnt/sdcard didn't work too. For example, the camera app still claims there isn't a SD card inserted.
edit: I also asked this on xda -> http://forum.xda-developers.com/showthread.php?t=1393395
There's no way for an Android application (constrained within the application sandbox) to create a loopback device.
Anything outside of this is not a developer question, and should be posted to another forum (e.g. https://superuser.com/).
I don't agree. Hanitaro Tide and PlasmaSoundHD both have created loop devices on my phone, all by themselves. On an x86 device it's even easier to fake an sdcard.img.p
I hope it won't sound like I'm up to no good -- I'm actually motivated by this problem -- but I'm trying to slurp down a raw disk image of the data partition of an Android device. Ie, not just the files stored there but all the orphaned file fragments and everything.
If I can achieve that then I can write some code to sift through that raw data and do some data forensics.
(I hope the recovery part of this question is sufficiently programming-related. I don't think I'm going to get an answer anywhere else and I intend to offer a large bounty for any answers here.)
Can't be done on "normal" devices via application: http://developer.android.com/guide/topics/security/security.html
Possibly it can be done on rooted devices, but this will depend on particular ROM. I guess you'd need a dd command.
It is unfortunate that the data is on the built-in storage. Does your phone automatically provide USB Mass storage mode access to the hardwired storage when you plug it into a computer? If so, you might be in luck still.
I'd suggest using a Linux machine and make sure that udevd(8) won't try to mount the drive when you plug it in -- you want to mount it read-only, which won't be the default. (Depending upon your distribution, it might have some other mechanism to automatically mount filesystems on USB mass storage drives when they are attached. If so, find them and turn them off.) Maybe service udev stop or /etc/init.d/udev stop are sufficient to stop udevd(8) from pretending it knows better.
Check dmesg(1) output to find the device name that the hardware takes when it is plugged in. I'll pretend it reports /dev/sde.
dd if=/dev/sde of=~/android_backup bs=4096
chmod 400 ~/android_backup
The if specifies the input file, the of specifies the output file, and bs asks for a blocksize of 4096. (There's nothing magical about 4096 -- it is the size of a memory page on many platforms, so blocks of this size can sometimes be moved around more efficiently than smaller blocks.)
The chmod(1) command makes it more difficult to modify the backup by removing write permission.
This makes a copy of the entire "drive" -- all the filesystems. This might be more difficult for programs to handle, so grab the specific partition your data is on while it is mounted -- it'll never be easier than now:
dd if=/dev/sde1 of=~/android_partition bs=4096
chmod 400 ~/android_partition
(If there are multiple, maybe grab them all. Disk space is cheap.)
Once you've got the image, you need to figure out how to salvage the data from it. It might be there, it might not be there, but there are some immensely helpful tools available that can help.
I've used Autopsy (part of The Sleuth Kit) before to recover deleted images from FAT-based camera storage. Granted, FAT is an easier problem, but they claim to support many filesystems, and it would be my first choice.
I haven't used Scalpel but it looks promising. It uses binary magic numbers to identify and slurps files out. It claims to be suitable for forensics use, but I don't know happily it will recover data from deleted files. (Since it claims it can handle raw partitions, I've got a good feeling about it.)
I've fiddled around with debugfs(8) before, but never used it when the stakes mattered. It looked amazing -- but also looked like it requires the user to have more advanced knowledge of ext* filesystems to do anything really useful. Read the manpage and guess if you think it's worth trying.
And don't forget you're not alone -- companies are available that can help recover data. (I've selected this specific company because I know Erik from this company and know him to be careful, thoughtful, and good at what he does. There are more companies than just this one but it'd be nice to find one that does more than just run Autopsy on images. You can do that.)