Valid HTML 4.01 Transitional

Samsung Galaxy S III
Hacking and Miscellaneous Setup

Jim Carter, 2012-10-23

To Do List

More-or-less Functioning Items:

Finished Items:

Installing Dropbear

While Dropbear was preinstalled on CyanogenMod-7, it isn't on CM-9 or CM-10. (/system/xbin/busybox is there already, a prerequisite for su.)

I installed (from the Market) DropBear SSH Server version 1.9.4 by Shk. Schneider. Install notes:

I also installed rsync backup for Android version 1.6.1 dated 2011-04-11 by Michal Kowalczuk. This downloads the binaries from the mother ship; apparently the author believes including them in the package may violate GPL.

Dropbear does accept publickey logins and rsync over ssh does transfer files successfully.

Restoring Application Data (Initial Installation)

Bookmarks: I installed Bookmark Sort and Backup by HappyDroid, and restored the saved bookmarks from before the Droid-3 died. Successfully, and I changed the setting to put the backup directory on the external SD card, and I restored /external_sd/htdocs, plus the three book directories (off Julia).

Restoring Application Data

Some OS image updates require you to wipe /data and /cache. (On the Samsung Galaxy S III, dalvik-cache is inside /data so you don't have to clear it separately.) This is always needed in a version upgrade, e.g. CM-9 to CM-10, and also when alpha-level software is involved. Also, if you're going to file a bug report it's a good idea to upgrade to the latest (stable) version and wipe data, then re-test your bug, since back-version app data sometimes sets off bugs. Here is my procedure to recover from a data wipe.

It's not a good idea to blindly restore everything, which would be the same as not wiping data at all. You need to restore selectively. Problems of this kind are seen when people make a backup with Titanium Backup or a similar product, and then restore everything.

Mounting the SD Card's Second Partition

See this posting about mounting partitions. OP is cdesai, 2012-10-03, announcing nightly builds for the OG Galaxy Tab and giving an installation HOWTO. There's an add-on by asvantypography, 2012-09-18 titled How to partition your SD card for Free Internal Storage.

The main point of links2sd is to move apps to the second partition and to leave symlinks to where they were moved to. This is not the issue for me; I just want it mounted. If you do use the links feature, see this HOWTO about links2sd by eraser0, 2012-07-14. He warns that links are also created in the Dalvik cache which you will lose if you wipe it. On the Galaxy S III the Dalvik cache is in /data and of course gets wiped if you wipe /data. Other phones have it in a separate partition so it has to be wiped (or not wiped) separately.


Here's a nasty tidbit that I found linked from some Dropbear documentation: Is Google Blocking Apps Writing to SD Cards? by Chainfire dated 2012-11-04 (although that's in the future and context suggests it's really 2011-11-04). Chainfire is a respected developer. Apparently this started in Android-3.x Honeycomb and continuing at least to Android-4.0.x Ice Cream Sandwich. The symptom is that apps which need access to the non-internal SD card and/or storage devices attached as USB clients can read but not write.

Apparently there is a new intent called WRITE_MEDIA_STORAGE, and a group to go with it, media_rw, which controls the non-internal SD card. There is a special hack in the code so that only apps signed with the platform key, i.e. not third party apps, can receive this permission.

Apparently a band-aid has been applied to this problem in CyanogenMod (CM-9 I suspect, from the date, and it continues in CM-10). Samsung has a different band-aid in their stock kernels for Galaxy S II.

Jimc reports the following:

The stock kernel (Android-4.0.4 ICS) for the Verizon Galaxy S III (SCH-I535, d2vzw) does not have Samsung's band-aid, and both SD cards' mount points have group media_rw. I got bitten by this because on the stock image the ADB server is not in this group, and so adb push is impossible.

On CyanogenMod-10, /storage/sdcard0/. has mode 775 root:sdcard_rw while /storage/sdcard1/. has 075 system:sdcard_rw. Thus apps whose sandbox user is not in group sdcard_rw, i.e. which have not posted an intent to read-write the SD card(s), get readonly access.

I have a speculation about this gross misfeature: If multiple programs are adding or deleting files, or are editing the same file, chaos can ensue which the carrier will be blamed for and which will lead to customer support calls that are long and expensive, and which the user will report on negatively afterward. If MTP is going to be used to transfer media files, I can easily imagine the carrier's software developers insisting on locking out other apps, at least from writing in the same area. Obviously media, i.e. large amounts of raucous music and pornographic photos and video, is the only file content that interests the typical purchaser of a cellphone, and so the SD card(s) are reserved entirely for that purpose. I agree with very little of this mindset, but I'll bet it's the source of the decision to lock third party apps out of write access to the SD card(s).