Archive for the 'Android' Category
Recently, one of my Android devices stopped reading the memory card. Opening the device, the microSD card was so hot I couldn’t hold it in my hand. The battery on that corner of the device had started to swell slightly. I’ve used this device every day for 3+ years without any issues. Until this week.
I also use TitaniumBackup to back up my Android to this external memory card, but since the device can’t read the card, I can’t back it up to the card.
The card is fine, and works in my other devices, as well as being seen from the desktop. Other, blank microSD card can’t be read in the device and similarly overheat within seconds. It’s bad.
Enter rsync, the Swiss-Army Knife of power, to back up my Android device!
- Download the Android SDK and unpack or install it on your machine.
- Plug in your Android via USB cable to your machine (Mac, Windows or Linux).
- Go into Settings → About, and tap on the Build Number section until you’ve enabled “Developer Mode”.
- Exit out of the “About” section, and now you’ll see a new menu option: “Developer Options”.
- Select “Developer Options” and go to “USB Debugging”, and enable it. This will enable you to manage your Android device over USB.
- cd into the ‘platform-tools’ directory and run “adb”, so we can find your device:
$ ./adb devices List of devices attached d682520f device
- Let’s use “adb” again and open up a shell on your Android device as root. We’re going to run the rsync process as root in a moment. We could run it as a normal user, but would be restricted in the files we are permitted to read from the device. To make things easier, we’ll just do this all as root:
$ ./adb -s d682520f shell shell@hlteatt:/ $ su - root@hlteatt:/ # id uid=0(root) gid=0(root) context=u:r:init:s0 root@hlteatt:/ #
- Now we need to create a configuration file for the rsyncd server process to use in a moment. Using the ‘vi’ editor, create the following file, call it “rsyncd.conf” and put it wherever you think it appropriate. In my example, I put mine in /data/local/tmp/rsyncd.conf. The contents looks like this:
address = 127.0.0.1 port = 1873 [root] path = / use chroot = false read only = false uid = root gid = root
- We need to download the ARM version of the rsync binary and push it to the device:
wget -O rsync.bin http://github.com/pts/rsyncbin/raw/master/rsync.rsync4android $ file rsync.bin rsync.bin: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
- Let’s push that binary to the Android, using “adb” again:
$ ./adb -s d682520f push rsync.bin /data/local/tmp/rsync 2357 KB/s (793148 bytes in 0.328s)
- To execute rsync as root, we have to adjust the permissions of that binary:
$ ./adb -s d682520f shell su - -c "chmod 755 /data/local/tmp/rsync"
- Run the rsync server process, listening on the standard port, by chaining the command through “adb”. You can also do this by logging into the Android via “adb shell” and running the same command directly. I’ve added the end-of-line continuation markers here so it doesn’t wrap wrong in this post:
$ ./adb -s d682520f shell su - -c "/data/local/tmp/rsync \ --daemon --no-detach \ --config=/data/local/tmp/rsyncd.conf \ --log-file=/proc/self/fd/2" 2016/09/25 23:05:17  rsyncd version 3.1.1 starting, listening on port 1873
All in one line here:
$ ./adb -s d682520f shell su - -c "/data/local/tmp/rsync --daemon --no-detach --config=/data/local/tmp/rsyncd.conf --log-file=/proc/self/fd/2"
- In another terminal/shell on your host machine, forward the rsyncd port from inside your Android device to a listening port on your host machine. This command should produce no output:
./adb forward tcp:6010 tcp:1873
- Now we can run rsync on the host to pull the data from your Android over to your local disk. Create a directory to hold your backup and cd into it, then run the following:
sudo rsync -avP --delete --inplace \ --stats --exclude=/proc --exclude=/sys \ rsync://localhost:6010/root .
- It should then show your device starting to back up to your local disk. When it completes, you’ll see a summary, similar to the following:
Number of files: 85920 Number of files transferred: 3040 Total file size: 39514100245 bytes Total transferred file size: 770291255 bytes Literal data: 215397682 bytes Matched data: 554901587 bytes File list size: 2311538 File list generation time: 10.609 seconds File list transfer time: 0.000 seconds Total bytes sent: 1529010 Total bytes received: 218618474 sent 1529010 bytes received 218618474 bytes 1842238.36 bytes/sec total size is 39514100245 speedup is 179.49
Why would I want to do this instead of using “adb backup”? That style backup packs files into a single, binary container. Using rsync, you have direct access to individual files on your device, without having to restore them first.
That’s it! You now have a full (and I mean FULL) backup of every bit of data on your device. You can now push that to an SD card, thumb drive, storage media or another Android device.
Playing more and more with Docker across multiple Linux distributions has taught me that not all Linux distributions are treated the same.
I am using this version of Linux to set up my own Docker lab host for tire-kicking, but it needs some tweaks.
I also wanted to see if I could use the Docker API from my Android phone, using DockerDroid, which (after configuring this) works famously!
Here’s what you need to do:
- Log into your CentOS machine and update to the most-current Docker version. The version shipped with CentOS 7 in the repo as I write this post, is “docker-1.3.2-4.el7.centos.x86_64”. You want to be using something more current, and 1.4 is the latest. To fetch that (and preserve your existing version), run the following:
$ su - # cd /bin && mv /bin/docker /bin/docker.el7 # wget https://get.docker.com/builds/Linux/x86_64/docker-latest -O docker # systemctl restart docker # exit $
Now you should have a working Docker with the right version (current). You can verify that:
$ sudo docker version Client version: 1.4.1 Client API version: 1.16 Go version (client): go1.3.3 Git commit (client): 5bc2ff8 OS/Arch (client): linux/amd64 Server version: 1.4.1 Server API version: 1.16 Go version (server): go1.3.3 Git commit (server): 5bc2ff8
- So far, so good! Now we need to make sure firewalld has a rule to permit this port to be exposed for external connections:
$ sudo firewall-cmd --zone=public --add-port=4243/tcp --permanent $ sudo firewall-cmd --reload success
You can verify that this new rule was added, by looking at /etc/firewalld/zones/public.xml, which should now have a line that looks like this:
<port protocol="tcp" port="4243"/>
- Now let’s reconfigure Docker to expose the API to external client connections, by making sure the OPTIONS line in /etc/sysconfig/docker looks like this (note the portion in bold):
OPTIONS=--selinux-enabled -H fd:// -H tcp://0.0.0.0:4243
- Restart the Docker service to enact the API on that port (if successful, you will not see any output):
sudo systemctl restart docker
- To test the port locally, install telnet and then try telnet’ing to the port on localhost:
$ sudo telnet localhost 4243 Trying ::1... Connected to localhost. Escape character is '^]'. HTTP/1.1 400 Bad Request Connection closed by foreign host.
All looks good so far!
- Lastly, install DockerDroid and configure it to talk to your server on this port:
Now you should be able to use DockerDroid to navigate your Images, Containers and API.