Android, it's alive!.. (2.0.1) - Updated 12/24

[EGOvoruhk]

Yet somehow the Android builds running on the Vogue via HaRET look just as fast as the ones running via NAND? I guess mine and everyone else's eyes could be playing tricks on them. Lord knows I've confused 50% speed for 100% speed multiple times. Why just this very morning I thought I was going 65 on the freeway until I got pulled over for only going 30

[citats]

Originally Posted by EGOvoruhk

Yet somehow the Android builds running on the Vogue via HaRET look just as fast as the ones running via NAND? I guess mine and everyone else's eyes could be playing tricks on them. Lord knows I've confused 50% speed for 100% speed multiple times. Why just this very morning I thought I was going 65 on the freeway until I got pulled over for only going 30

LOL

Android caches heavily, if that cache resides in memory it will be fast, however these early builds as promising as they are, yet the cache seems to be going to the sd, causing pauses in executing previous commands.
I said what I did simply because it is fact not because I am against Haret, I am not and will use it when available.

[animez]

I downloaded Spb Benchmark to find out if the NAND memory is faster or not, rather than have everyone continue to lob forum grenades back and forth. I ran the read/write tests on the main memory and my 8GB Sandisk class 4 SDHC (all times are milliseconds, pasted from the xml results file);

fs=fixed storage
sc=storage card
manyfiles=10KB file x 100
largefile=1MB file

<fs-largefilewrite> 440.600000
<sc-largefilewrite> 1518.500000

<fs-largefileread> 37.100000
<sc-largefileread> 264.600000

<fs-largefilecopy> 492.600000
<sc-largefilecopyto> 326.200000
<sc-largefilecopyfrom> 472.900000

<fs-manyfileswrite> 3919.600000
<sc-manyfileswrite> 4971.400000

<fs-manyfilesread> 385.700000
<sc-manyfilesread> 555.900000

<fs-manyfilescopy> 3482.200000
<sc-manyfilescopyto> 2744.400000
<sc-manyfilescopyfrom> 2811.300000

<fs-dirlisting> 2201.400000
<sc-dirlisting> 214.900000

While some results were about what I would expect (large file tests) the SDHC holds it's own. Someone with a class 6 card should run this and post their results as well.

[sledgie]

For all of you having problems with it, obviously #1 make sure your microSD card is CLEAN and formatted FAT32.

#2, download the build to your computer. then hook up your TP2 to your cpu via usb cable. select disk drive mode, and then Unrar/Unzip it to your microsd card via your computer, ie, extract to... F: or E: or whatever the Drive name is of your microsd card connected to your computer is.

Originally I tried unzipping it to the card via the card and via storage memory and i was NEVER able to get it running until i unzipped it to the card via my computer/usb cable.

when you see the multi colored X tap it a few times, wait 2 min, tap a few more times, wait 2 min, etc.

I have used the microsd card that came with the original TP, on the 1st time it boots it takes ~5-7min, after that it takes 2-3min.

Good luck!!!!

[The Lance]

My android works just fine.. but what is it with the horrible screen calibration.. I can barely get it to unlock at the unlock screen..

The latest build is way worst then the one before it screen calibration wise..

[The Machinist]

Originally Posted by The Lance

My android works just fine.. but what is it with the horrible screen calibration.. I can barely get it to unlock at the unlock screen..

The latest build is way worst then the one before it screen calibration wise..

open your startup.txt, change the msmts_calib to :=0x9f.0x39a.0x35c.0x78

save

reboot HaRET

enjoy.

[The Lance]

Originally Posted by The Machinist

open your startup.txt, change the msmts_calib to :=0x9f.0x39a.0x35c.0x78

save

reboot HaRET

enjoy.

did not help very much... I'm assuming that Machinist's Calibration

[cd993]

seems like developers over at XDA have started work on hero...

http://forum.xda-developers.com/show...596370&page=21 post 205

[The Machinist]

Originally Posted by The Lance

did not help very much... I'm assuming that Machinist's Calibration

at least it gets you to the edges of the screen! Niether of the two previous ones were very accruate. 0x7a.0x37f.0x35a.0x5e was too low in Y and 0x6a.0x3c1.0x376.0x8a was too high in Y and both had problems in X.

The first thing to determine was what numbers control which direction. the 1st number controls the pointer location in X(+); how far it can go right, the 2nd number is Y(+) how far it goes up, the third is X(-); left and the 4th is Y(-); down. And based on the values of all four numbers determines where the center will fall. Too much in Y(+) makes for a high center etc...

Now adding "3c1" to "37f" and divding by 2 on my calculator didn't yeild very good results (since mine doesn't add letters very well) so I guessed using a method I could never explain logically.

What I came up with seemed like a decent solution according to the "Pointer Location" within the "Dev Tools" app. in the eclair build. If anyone determines a better one I"ll be glad to use it!