[TESTING] XDAndroid GBX0C 2.3.7 Build - Page 30

**arrrghhh** · #1 (**permalink**) 03-20-2012, 05:00 PM

Quote:

Originally Posted by auburnham

Thanks for the feedback arrrghhh.
1) I'd still like to understand why I've seen little effect of changing minfrees after the 9/30/11 rootfs.img. If anyone has a suggested way to investigate, I would be interested in hearing it. Perhaps I could compare every file in this rootfs.img to the 9/20/11 rootfs.img for changes? Also, what are others' typical free memory just after boot and after a reasonable uptime?

2) I'm experimenting with badboy8813's AudioPara3.csv, and it seems to work quite well at boosting the volume. I'll post if I run into any problems with it. If that doesn't work, I'll try rete's Volume+ rec (thanks, rete).

3) Voice Search wasn't included with the GBX0B bundle like it was with FRX07.1, so I didn't know I needed to install it. It is now installed and mic button is present.

The rootfs.img change isn't indented to resize the data.img, it is intended to create the data.img with a larger size. Much cleaner, IMO. Plus, I often have to recreate my data.img because of SD card issues, and the rootfs.img change saves time in the long run. Looking forward to a NAND build with as many working features as GBX0B.

1) Minfree settings from the SuperCharger script or from manual intervention should still work fine. Why do you feel they're not being set properly? Keep in mind, it gets to a point where you just can't free up any more memory - I don't know how Android behaves if you set the numbers to something insane, I would think it would kill applications very quickly, perhaps even when you're using them lol.

3) Hum, I didn't do anything special to include it in FRX, that I know of... I'll look into it, but IMHO this is trivial - does AOSP include it?

Also, you can generate a blank data.img file to always replace yours... but do what you gotta do, I just would not recommend everyone hack the rootfs. There's much easier ways to get a bigger data.img file, lol.

Also, for me - NAND seems to work really damned well. I rarely have WinMo flashed on the device at all anymore...

auburnham · #2 (**permalink**) 03-21-2012, 12:52 PM

I've been experimenting with bluetooth, and I found a reproducible problem when dialing from the handset. If bluetooth is connected, and a call is initiated on the handset, it automatically switches audio over to the bluetooth connection. The audio is successfully routed through bluetooth for a few seconds, but then audio is lost. After this, all audio is lost on the device, even after the call is dropped: No bluetooth, no earpiece, no speaker, no 3.5mm, no extUSB, etc. A reboot is required to reset audio, and I've only tried cold boots. Audio is reproducibly broken after repeating the sequence.

EDIT: This problem was caused by badboy8813's AudioPara3.csv. Returning to the original AudioPara3.csv resolved the problem.

Quote:

Originally Posted by arrrghhh

1) Minfree settings from the SuperCharger script or from manual intervention should still work fine. Why do you feel they're not being set properly?

I believe the minfree settings are being ignored because there are processes in categories that should be killed with the given memory condition, but they are left alone. For example, my Hidden Applications minfree setting is at 64MB (admittedly aggressive), yet, while my memory drops below 40MB these programs continue to run.

auburnham · #3 (**permalink**) 03-31-2012, 06:58 PM

Quote:

Originally Posted by auburnham

I'd still like to understand why I've seen little effect of changing minfrees after the 9/30/11 rootfs.img. If anyone has a suggested way to investigate, I would be interested in hearing it. Perhaps I could compare every file in this rootfs.img to the 9/20/11 rootfs.img for changes? Also, what are others' typical free memory just after boot and after a reasonable uptime?

I had an opportunity to investigate this further. I compared all files changed from the 9/20/11 rootfs.img to the 9/30/11 rootfs.img, and identified the change made by mweirauch labeled "fixup /dev/block/ramzswap0 creation" to be in /bin/userinit.sh, line 317. Originally, it was the following:

Code:

mknod -m 0666 /dev/block/ramzswap0 b 254 0

And it was updated to be the following:

Code:

mknod /dev/block/ramzswap0 b 253 0

When I revert back to the original line, (i.e. ... -m 0666 ... 254 0) my free memory is consistently higher and my performance is better without any obvious side effects. Can anyone explain what this line is doing, and why I might see the effects I'm seeing? Also, just to be clear, I am not recommending that anyone make this change, I am just trying to investigate potential performance improvements.

**arrrghhh** · #4 (**permalink**) 04-01-2012, 12:41 PM

Quote:

Originally Posted by auburnham

I had an opportunity to investigate this further. I compared all files changed from the 9/20/11 rootfs.img to the 9/30/11 rootfs.img, and identified the change made by mweirauch labeled "fixup /dev/block/ramzswap0 creation" to be in /bin/userinit.sh, line 317. Originally, it was the following:

Code:

mknod -m 0666 /dev/block/ramzswap0 b 254 0

And it was updated to be the following:

Code:

mknod /dev/block/ramzswap0 b 253 0

When I revert back to the original line, (i.e. ... -m 0666 ... 254 0) my free memory is consistently higher and my performance is better without any obvious side effects. Can anyone explain what this line is doing, and why I might see the effects I'm seeing? Also, just to be clear, I am not recommending that anyone make this change, I am just trying to investigate potential performance improvements.

Hrm, I'll see if emwe remembers why he made that change. The only difference I see is the permissions are not being set on the updated line (no -m 0666) and the file size is 1 byte smaller? b 253 instead of 254.

The manpage on mknod will help you understand a bit more what's going on perhaps?

mknod(1): make block/char special files - Linux man page

As to what the default is for permissions, or why you would be seeing different performance is strange indeed. Have you taken my newest rootfs from this bundle and changed that line? It works, you get tangibly better performance?

rete · #5 (**permalink**) 03-20-2012, 03:29 PM

Quote:

Originally Posted by auburnham

2) arrrghhh mentioned that the volume could be increased by modifying the .csv files. My audio is quiet, but not more than it was with FRX07.1. Can someone tell me what data in what .csv file needs to be edited to increase volume?

Volume+ does wonders on various of my GB devices (TP2 with OMGB nand; HTC Desire; Nook tablet). It might work for you.

EyeB · #6 (**permalink**) 03-20-2012, 10:13 PM

This has happened a few times now so I'm fairly sure it's reproducible for other people

But I connect my phone in winmo to laptop (using activesync, no choice to just charge) to charge phone. While plugged into laptop, I start up haret to launch android. It does it's startup thing (long list of text scrolling down, don't know better way to describe it). But instead of going to the XDANDROID flash screen, it books back into winmo. I can't say it does this everytime, but it happens fairly often that I think someone else might be able to reproduce it

don't know if this is a known issue, but it's fairly new to me, but i just recently started charging phone from laptop instead of wallcharger too

edit: but it starts android fine if i unplug phone before running haret, so I'm not sure if it's activesync or laptop doing something, not even sure it is worth "fixing" but it's better to know about it then not?

**arrrghhh** · #7 (**permalink**) 03-20-2012, 11:10 PM

Quote:

Originally Posted by EyeB

edit: but it starts android fine if i unplug phone before running haret, so I'm not sure if it's activesync or laptop doing something, not even sure it is worth "fixing" but it's better to know about it then not?

This was going to be my suggestion, lol.

Ironically with the RAPH you have to boot like this if you want to be able to use ADB.

wizardknight · #8 (**permalink**) 03-23-2012, 08:22 PM

Maybe the http://forum.ppcgeeks.com/android-tp...a-support.html
could be added in, or is that to far into testing still?

**fishingmedic** · #9 (**permalink**) 03-24-2012, 10:39 AM

Arrrghhh, any chance of taking a look to see why the "new" market, google play, doesn't seem to like the phones? IIRC it's something that needs to be hacked in the build.prop, but you know me, I'm not the one to start hacking around, who knows what damage I can do lol

detule · #10 (**permalink**) 03-24-2012, 11:07 AM

Quote:

Originally Posted by fishingmedic

Arrrghhh, any chance of taking a look to see why the "new" market, google play, doesn't seem to like the phones?

What's wrong with google play? (It's been on my phone for a while but other than installing apps I haven't used whatever other functionality they may have bundled with it)