[Fascinate Android Development] GizmoDroid:
Part 4

GPS power toggle from Drop Down Menu

The GPS option from the drop down menu is essentially broken and needs to be fixed. I recall a similar problem on a different device with the wifi. With that device, on observation, I noted that on powering up wifi from the settings menu, I would be connected within 5 seconds, but from the power widget, it would take a full minute. After doing some investigating, the power widget was basically trying to control the wifi device directly. I found a different widget that essentially emulated the same method used in the system settings menu, and it starting connecting immediately. My guess is that the GPS power code on the pull down menu could be modified using the same examination/modification needs to be adapted in the same way.

EVRC-B Phone Voice Codec

Switching to the EVRC-B codec improves call quality substantially, for both parties of the call. If anyone knows of a way to set it that doesn't involve going into service mode and manually changing it, then please let me know.

Background Noise Cancellation during call

Also, I'd love to find a fix for the mic during calling. It's a frequent occurrence for the person I'm calling to be like "Who are you talking to?" because they hear someone talking

in the next room away from me.

Or a very light sound on my end, elicits a response of "WHAT IS THAT NOOOISSSE??!" from the person I'm talking to. So obviously an issue of background noise cancellation. I'm hoping its a software fixable problem.

I've seen this build.prop edit to mess with the noise cancellation for disabling noise reduction for the voice recorder (Say you are trying to record something like music, or something at a concert, the noise filter would hinder your ability).

media.a1026.nsForVoiceRec=0
media.a1026.enableA1026=1

Two things about this:

1. I've only seen this kind of property on other devices that have two mics that work in combination for noise cancellation. I'm guessing the SF only has one, and any attempted noise cancellation is done at the hardware level or in software.

2. This would assume that the noise shield actually exists, but the stock Fascinate behavior is to not have it enabled for calling... which is pretty dumb. Given some of their other decisions, this may be true, but I have my doubts. If it's parameters are accessible, and it's merely only needing some tweaking, then I will be happy.

I wonder if supercurio knows much about the noise cancellation, since he's worked with so much of the sound stuff?

Disabling of debugging stuff and additional code checking

Debugging stuff is essential for figuring out problems, but for the 99% of the time, isn't it probably slowing us down? I don't know what would be the best way to easily disable any additional debugging routines that might be affect performance.

As for disabling code checking, I used to run these build.prop edits on an older device. I have no idea if they still apply:

ro.kernel.android.checkjni=0
dalvik.vm.checkjni=0
dalvik.vm.verify-bytecode=false

Maybe you are the kind of person that needs their phone fully stable at all times (no you're not, because you are on a forum that is made to push your device to the limits). I, however, keep everything backed up, so if disabling this extra "security" might slightly increase risk of data loss, then I'm okay with that (not saying that this is an actual danger, but just in general). The only problem I have is if the increase is negated by a large rise in errors that actually hinder performance, or if it becomes significantly more risky (doubt that's the case, but it's always a possibility).

Somewhat related, we currently keep the dalvik heapsize at 48mb's. Is this the best match for our device, or just the default?

PNG/ogg optimization and Zipaligning

I recently took a superclean rom, and dropped 16MB losslessly just from throwing the pngs through PNGOUTWIN and deflopt (didn't touch the *.9.png files). Free RAM right there. Not to mention that some of those APK's have ridiculous extra resources that can be reduced by cutting color depth or taken out entirely (giant HTML based tutorial files stored in the apk... why?) Also, all of the ogg files can be slammed down using a sox script or an equivalent.

In compression, it's also important to know when its a free and harmless, or when it will reduce stability. You can zip up an APK nice and tight... but aapt is a better method. The files might be bigger, but they will run better (also, learn how to treat *.9.png files, or don't touch them at all).

I've adapted the script from Bugless pete's automatic, on-phone zipaligning utility (just had to change a couple lines). A lot of times there are apk's that slip through the cracks in the ROM's that aren't zipaligned (especially in themes and patches). Again, just free performance that isn't hard to obtain.

libdvm.so Optimization

Has our libdvm.so been optimized to run on on our processor? I know this was a huge boon for older devices, but couldn't find any info on ours.

Battery Service Polling

Ever watched the logcat even when your device is nearly at idle? Ya... that battery is always updating. How do we change this habit? I often wonder how much extra juice would we gain by increasing the length in between battery polls.