| Selection | Checkout | Install | Apps | Hacking | Top |
Unscramble SOGo server for the contact list.
Input methods, investigate every credible one in the market.
The stock image for the system partition is 820Mb in size. Investigate what takes so much space. See bloat.shtml.
Mounting the second partition, and start using the 32Gb SD card. That is a prerequisite for installing Debian.
Looks like all you have to do is edit /system/etc/vold.fstab, adding the new mount, and add something to something to mkdir the mtpt.
Device path is /sys/devices/platform/msm_sdcc.3/mmc_host/mmc1 , specify partition #2 explicitly. What is partition #3 on this card? Linux swap (not used). The resulting fstab line is:
dev_mount sdcard2 /data/local/extsd-2 2 /devices/platform/msm_sdcc.3/mmc_host/mmc1/
/init.qcom.rc creates the mount points and issues the mount command. Hacking it is going to be hard because it's copied from somewhere on each boot, and I can't find the original. I made a directory: /data/local/extsd-2 owner root:sdcard_rw mode 775. But vold does not mount filesystems until told to. That's where I left it.
What magic is preventing Xena from accessing Selen, whichever originates the connection, whichever address family?
The issue is, both Selen and Xena are wireless, and can't see each other unless the AP bridges the packets. To fix: /etc/hostapd.conf bridge_packets=1 from hostapd-1.1.4 which we don't have. SuSE Build Service has 1.0, maybe it has this parameter.
Debugging the user X.509 certificate. Is there a usable cert manager in the Market? No. Get rid of the expired certificate.
/data/misc/systemkeys contains one file, AppsOnSD.sks. It is binary, 16 bytes, no strings. Irrelevant.
/data/misc/keychain/cacerts-added: This is the only subdir. Content is CA certs, only those added by the user, in DER, named by proper subject hashes.
/data/misc/keystore: These are X.509 objects but all are binary
but not DER. Probably encrypted with ./.masterkey. Their names are
$UID_$TYPE_$FRIENDLY, i.e. the UID of the currently logged-in
user (in decimal), the type from CACERT, USRCERT, USRPKEY, and the
friendly name with nonalphabetic chars mangled (likely unicode).
What happens if I delete the user cert believed to be defective, i.e. expired? Didn't help. The browser asked to present the correct cert, but still failed to make a secure connection. Error message is: Couldn't establish a secure connection.
I tried the following browsers. All of them got less far than
the standard browser, i.e. they did not even attempt to pick a
client certificate, and reported various generic or custom error
messages such as Unable to complete secure transaction
.
I think all browsers use generic infrastructure to read URLs, and this has a bug. Now, who to report it to? See the bug report on the X.509 problem.
Unscramble voicemail.
See the bug non-report about the dialpad.
Called *611 (customer service). Could not find a human to talk to. Automated options are all irrelevant. Same automated service from the landline 1-800-922-0204.
I sent e-mail from their contact us
page. Wish me luck.
The answer was how to reset the password on the Backup Assistant
service, totally irrelevant. Idiots!
Voicemail procedure: in the phone app settings, find voicemail setup. For the number to call: *86 comma comma pass-number. In the GUI press the #* key and you will get a sub-menu of symbols, one of which is pause, represented in the dial string by a comma.
From a landline, dial your mobile number, reject the call (or don't answer) on the handy, press # before the voicemail greeting finishes, enter the password when it asks, followed by #.
I changed my voicemail password on their web form to a 6 digit number. I was never able to authenticate with this password. I tried several different ones. They say you can have 4 to 7 digits.
I changed my password from a landline. Call 1-800-922-0204 (customer service) and go through the menu to voicemail password changing. Let them select the password; you get 5 digits. (Write it down.) Now I can authenticate and hear my voicemail from the landline.
Endless trouble with the dialpad. Once you dial the call, you then can't send DTMF (digits) to the response system. Press digits (or #*) on the dialpad and they are echoed in the top row but the partner does not hear them. I also tried with a Bluetooth keyboard and the effect was the same as on the dialpad (and pressing enter either had no effect or terminated the call, depending).
Searching on Google reveals no useful fixes. This sounds like material for a bug report, but which program is responsible, who do I file it with, and if with Google, will it just go in the bit bucket?
I tried a different dialer app called exDialer. Its major claim to fame is improved integration with the contact list. You dial the call on its dialpad, but in-call activities, including the dialpad, are the same (and have the same bugs) as with the native phone app.
Next plan: program ,,,,1 which should make it play back
the voicemail, even if I can't delete it. 2 commas weren't enough,
4 worked out. This makes it play the first message, but afterwards
you have to delete, archive, etc. by pressing a number, and it won't
automatically go to the next message. You have to hang up. The next
time you call voicemail you get the next message. To actually delete
the message (which is in a skipped
state) you need to do the
landline procedure. The final number
used is *86,,12345,,,,1 (password changed to protect the guilty).
This issue is not exactly finished, but has an adequate Band-Aid.
Update: I upgraded to the newly released stable version of CyanogenMod for d2vzw, cleared data only for the phone app, and the problem was cured; the dialpad is now usable on call. I retained the voicemail number including the password.
Install Dropbear and get it working.
Reinstall backup-host and speedtest. Do the speed test. The standard task is a SHA-512 sum of 5e8 bytes, which took 32.7 secs. This is a respectable speed for a low-end desktop machine. Two instances took as long as one: dual cores were used.
Update: I have a new speedtest program with the same task, but it reports in bytes/sec, and it also does an I/O test, just cat files in /system and /data to /dev/null. The composite score is 3/8*SHA + (cores*1/8)*SHA + 1/2*I/O Results:
Battery life statistics using Antutu. Done, and recorded in checkout.shtml.
Check out Bluetooth. Phones: checked, OK. OBEX: no functional partner. Keyboard: checked, OK.
Feature test: WiFi in master mode. Works.
Data speed test. 4.16e6 bit/sec on 4G LTE. One reviewer got 3.5e7 bit/sec. My signal strength is kind of low, though.
There are several apps I haven't reinstalled. Do that, and try to restore their data where appropriate. [Done.]
Restore as much app data as possible. Done, the only app data worth saving was for Andoku and Bookmark Sort, and these were restored successfully.
Phone Tester by Miguel Torres: sensors page freezes up. See bug report about Phone Tester.
Check out music playback. Pick a decent music player for the various music sources.
DeaDBeeF player worked well. Plays Ogg and MP3 (with codec pack) directly, and Icecast and M3U stuffed with either of these. It accepts URLs from the browser and performs them.
Test if DeaDBeeF will pause during a phone call, then resume. According to the config file, it should be able to do this.
Update: wouldn't do last night what it did the previous day. It went catatonic whenever started: blank screen, nothing, until the ANR notice appeared. See this bug report about DeaDBeeF for a fix.
App writeup for DeaDBeeF: DeaDBeeF Player by Aleksey Yakovenko (free/pro) -- Medium popularity, good reviews. Only player that advertises ogg. Get free plugin pack for MP3 etc etc. Ad supported, pay $1.90 for pro version, to get rid of. Installed, it handles Icecast and M3U from browser.
Need to deal with locally stored music.
What is the preferred way to get the music onto the phone? iTunes? MTP? How corporate, how ungeek! This works for me:
wget -O - $URL | tar xvf -
Playback app, will DeaDBeeF be OK? Yes.
Add Folderat the bottom. All recognizable tracks will be added to the default playlist. Likely you can add selectively also, or add (or utilize) a M3U playlist, but I haven't tried these yet.
How to delete music: rm -r /sdcard/Music/dirname
Check out the front and rear facing cameras under CyanogenMod. Including barcodes. (They work on the stock image.)
I got Barcode Scanner by ZXing Team. I left the default setting to use auto focus, only standard focus mode (continuous focus did nothing). The flash (in flashlight mode) can illuminate the target but was not needed even in 16 lux (indoor artificial light at night). It was able to capture a UPC code and a QR code (and to follow the contained URL).
Front camera works, tested with IP Webcam. Camera app can also be switched to use the front camera.
Rear camera also works, including flash, and flashlight mode. This is all in CM-10.
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:
Install Dropbear. Click it. Super user privilege is requested, allow it. The app is installed. (Don't start the server yet.)
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.
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).
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.
Before you begin the upgrade, dump the /data partition. You definitely can exclude dalvik-cache, and there may be some bloated items in /data/media that you don't want to restore. I have the Dropbear SSH server, and on the backup host I do this command line. The resulting TGZ file is 162Mb; uncompressed it is 298Mb.
ssh selen "cd /data && tar -cz --exclude=media/cmupdater --exclude=media/Music --exclude=dalvik-cache -f - ." > selen-data.tgz
Turn on Menu -> Developer Options -> USB Debugging. This is required before you can use ADB.
Restore all the downloaded (non-included) apps that you intend to keep on the new version. Data comes later. I have a script to restore the apps. Run it as root, because Android sets weird permissions preventing an ordinary user from reading the data to be restored. The following apps are/were in /data/app but were already installed (in CM9-01-12); these were skipped by the script.
For apps that you downloaded, i.e. that did not come with CyanogenMod or Google Apps, you're pretty safe restoring their data too. Need to show how to use the scripts.
Selectively restore data for apps with APK files in /system/app. In a CM-9 upgrade I restored 21 of 93 apps. Run it as root, because Android sets weird permissions preventing an ordinary user from reading the data to be restored. Oops, at least one of the selected apps makes the UI crash, causing a bootloop. Symptom: within about 10-15 secs the phone reboots. You can unlock the lock screen (still reboots). You have just enough time to long-press the power button, select power off, and confirm it.
Recovering from the bootloop: I wiped /data and reflashed the OS image. I drastically pruned the set of apps that were restored (successfully), to just 7 of 93.
One of these two was the culprit causing the bootloop:
Set up wi-fi. I can't find the file that stores the wi-fi connection information. (Update for CM-10: /data/misc/wifi/). I did find the Bluetooth info, but there is a fix for Bluetooth problems in this image, so I'm reluctant to touch the data.
Restore Dropbear. See the instructions above, but you can just copy the data. (Update for CM-10: for the app I've installed, the host key, authorized_keys and known_hosts are kept with the app data and so do not have to be restored separately.) However, ADB does not set the source permissions at all, so you have to use tar, like this. Run as root, so you have permission to read the secret key.
touch /tmp/dropbear.tar
chmod 600 /tmp/dropbear.tar
cd /backupdir/data
tar cf /tmp/dropbear.tar dropbear
adb push /tmp/dropbear.tar /tmp/dropbear.tar
adb shell # Now executing on the phone
cd /data
tar xpf /tmp/dropbear.tar
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).
| Selection | Checkout | Install | Apps | Hacking | Top |