Skip navigation.

Linux Stuff

Tilting at Windows

Too busy to break stuff

The Android phone is staying stable with Cyanogen's 3.4.6. The phone is running really well with the new 8GB class 6 card. It still gets slow down after running some apps, but the garbage collection can't work miracles for demanding programs.

I upgraded my computing power to the tune of a i7 920 and an ASUS P6T. Hyperthreaded quad-core 2.7 GHz + 6 GB RAM = MythTV build in just under 3 minutes. I still have some work to do in getting the ATI HD4870 working well. I guess the fglrx driver doesn't support newer kernels (>2.6.26).

Too much of a good thing

I just can't seem to say no to apps. Having better hacks for running off of SD doesn't help the matter either.
I finally purchased a few apps (SNES/Genesis/NES emulators, a camera phone touch up app, and Tim Hoeck's clever LaunchIt app). I am using ~ 100MB or so, meaning that if the G1 had twice the flash (or at least as much as the Magic) it would be a very nice fit. I don't think that I want too many more apps; possibly less installed.

The latest status is:
  • A Class 6 8GB SDHC on order (this 2GB slow card doesn't cut it).
  • I just updated to CyanogenMod ROM build - it is roughly the JF ADP 1.5 build with some nice tweaks.
  • The new build has e2fsprogs for fixing filesystem on device and ext3 support, but I haven't been having as much trouble with the apps2SD lately.
  • I still need to update the repair image to Cyanogen's


A lot of thanks go to Simon Walker and his efforts with JAB

Respect the Dalvik Cache

On Android, Dalvik is the virtual machine for the Java-like application environment. Several writable directories are used for installation and operation:
/data/app - installed .apks (Android packages)
/data/data - storage for .apks
/data/app-private ? more storage?
/data/dalvik-cache dex files

Moving dalvik-cache can potentially save space ,but care must be taken when moving files and setting up a new link. This is the running space of the program, so it can critically interrupt a program (including important system apps) if the apps are "live". The other concern is that this storage is critical for performance of applications. Moving the cache to a SD card that is a little less than class 6 (32x 4.8MB/s Class 4) proved to be a killer with intensive apps (imeem made other apps unusable).

After numerous failed boots, wipes, re-installs, and horrible performance, I decided that the gain is not enough for moving the whole dalvik-cache to SD. A high-speed SD may help, but I don't need that much more space.

Is it still a phone?

Whew, I resurrected my phone (again) after too much hackery.
I had noticed some hesitation (turns out this was exceptions flying out left and right). Then I call a call, BAM dialer app fails, and again, I try to call a number with it, phone goes nuts, eventually gives up. Sadly, I didn't notice the "telephone" issue of the phone until the next day. It turns out that going in between Dev phone (ADP) and T-Mobile (US) versions may require a wipe. It was exacerbated by a mix of old app files/cache on the SD. After a number of wipes/re-installs, I am back working (actually better with more /data space after moving dalvik-cache to SD).

Some notes:
get a list of installed apps
copy .apks off semi-regularilly
- latest JF image requires delete of Browser.odex + reboot for "multi-touch"
write down the system settings preferred + any important app settings

I thought I had a stroke of luck when a number of apps showed up in the Market after update, but the still had problems/required updates so I ended up installing them all again anyway.

apps2SD

/data/data
/data/app
/data/dalvik-cache
? /data/app-private

SD ext2 partition mounted on /system/sd
make directories and symlink (ln -s)

Updated G1 Android version

With the release of the the US Cupcake (Android 1.5) release finally reaching the US, JF provided a new 1.5 based build. Having done these switches a couple times, I have figured out some helpful tips along the way.

Have the device on the charger, with over 30% before starting.

Install HardSPL so that you have a nearly foolproof restore option. Aside from the recent problems people have with Haykuro's newer radio files, most of this hacking will not "brick" a phone.

Backup local files on the phone. If you have stuff like shopping lists/OI Safe/whatever - write the files out to the SD card for re-importing later. Some programs may not support this (unfortunate). It may be possible to dump their sql databases; I would like to figure that out for next time.

Devote a couple hours free time with no phone access. Tinkering can waste away the hours with an unstable phone.

Have a microSD capable reader with an OS that supports doing a fscheck on ext2. I have had problems with apps on SD which sometimes require fixing filesystem errors. The hacks to get apps working this way still seem prone to problems booting the phone when there are filesystem errors.

Remember the key combonations for Android booting:
http://www.htc.com/www/support/android/adp.html
Home = Recovery
Camera = Fastboot

General
Call+Menu+End = Reboot

From recovery you can run Nandroid (JF builds), which will make zip files of the partitions and copies them on to the SD card.
From Fastboot you can use a Fastboot utility to restore the system from Nandroid images.

It is a good idea to run adb logcat during the bootup to watch for problems. You can see if Android is stuck booting (usually a error that causes a never-ending retry loop - often from filesystem problems). Sometimes the upgrade takes a long time (re-registering programs). I found that switching from ADP to US requires re-installing apps, becaus the permissions were all invalidated. With apps2SD, the market can sometimes be out of sync with installed apps, it is easier to install aTrackDog to check for updates than re-installing all of the apps by searching. It would really be helpful to figure out a way to automate the process of re-syncing the market (even if it required user confirmations).

I had to re-install system files for the HTC pdf reader
  • adb push libpdfreader.so /system/lib/
  • adb push FilePicker.apk /system/app
  • re-install pdfreader.apk


T-Mobile G1 and Google Reader

I am still experiencing issues with my G1 and Google Reader. Sometimes I can't set feed items as read. Since I just updated to the Haykuro H2 Cupcake build, everything has been snappy and stable except for the Reader issue. I have space, I don't get low mem warnings, and the error still happens. I am thinking there is a problem with sending the packets to google through T-Mobile's network. I think that the behavior is happening when I am on cell network, not wifi. I haven't noticed whether 3G/Edge factors in. I will try to notice more in the future.

With A2DP opening up my bluetooth world, I have noticed that turning on bluetooth (hence starting the scanning) can fight with the wifi. I guess that is what the new chips and Bluetooth 3.0 are for.

UPDATE - nope, the problem is not because of T-Mobile. The problem has occured on WiFi.

UPDATE - Google fessed up, it was a bug on their side. I am glad that is over with.

Cupcake

I took the plunge and updated to Cupcake (Haykuro build H2 with Apps2SD). Overall, I am pretty pleased with the experience. The 1.5 firmware for Android is definitely a notch better. A2DP stereo bluetooth is great, although I still had some connection issues - sometimes audio does not seem to link to bluetooth. The touchscreen keyboard is ok - it is fast for quick short strings. The recent turmoil over unstable APIs resulted in a few applications no longer working. The majority of failures are related to "settings" applications - ones designed to act as quick switches for phone settings (brightness, GPS on/off, Wifi on/off, bluetooth on/off, etc). A quick search for "latitude" provided an application to re-enable the latitude service (disabled in distributions not target at US).

Something interesting I noted in the mailing lists, was the naming scheme of Android branches. Cupcake is to be followed by donut. Since it is alphabetical (and seemingly pastry related), it makes me wonder about future releases. My money is on eclair.

G1 instability w/ SD app hack

I am getting errors associated with having the applications on the SD card. Sometimes installs fail, sometimes they will succeed, but corrupt after running once, and I experienced a "low memory" error on the browser today. This may be related to an issue I am seeing with Google reader.
Reader issue:
Sometimes feed items cannot be marked "read". This fails most with mark current page as read, but mark all as read will fail as well. Steps that seem to temporarily fix the issue (it comes back) is clearing cache/history, or loading another page and coming back.
There could be a memory buffer issue, an ext2 filesystem issue, or possibly the speed of the SD card is causing problems.

Write problems result in half installed apps, and instability (crashes, or fail to load home screen loop). When the phone is powered down, the SD ext2 filesystem seems to get corrupted. When the phone boots, it gets stuck in a loop trying to mount the sd apps partition. I will look forward to a more well thought out solution from Google as opposed to this community hack.

G1 updates

I just finished updating to HardSPL on my T-Mobile G1 Android phone.
Current running config:
HardSPL
JFv1.42_RC33
still on firmware 1.1 - until the Haykuro Magic builds get a little better
apps on SD + app-private by hand - 2GB cheapo MicroCenter microSD

Take two at social networking

One year later.
Android phone at my side, I am perpetually connected.