[Galaxy S I9000 Android Development] lotacus:
I suspect that people are not completely forth coming whether it's intentional or not. The re-occurring issues that people keep reporting are just not noticeable or reproducible by myself. I would rather not here a thing about battery life issues for the reason being that battery life is based on several factors and those factors have an impact on battery usage and are completely operator (ie phone user) controllable. Phone signal strength, sensors, wifi, any 3rd party application or system application that needs to poll for a particular state/status, phone usage, data usage, etc, all have an impact. If I were to get really annoyed, I would have posted, "change the way you use your phone".

I'm sorry, but I cannot get around thinking that high battery drain is an issue with the firmware, because it's not. The issue is with the person using the phone, how they are using it, and what they are using it for. This is very evident if one took the time to read through most of the posts. This is why Galnet stated that battery issues are "mixed" results. Of course, I will add that there was a minor instance where it was in fact the result of the firmware/kernel, which HAS been resolved a very long time ago, in terms of releases. Galnet based his first release off of 1.6.17 and pretty sure he wouldn't make drastic changes that would bring back old bugs, I don't think he is that negligent.

What is verified by me to be working and not an issue.

DATA*, WIFI, Phone calls, mms, text message, 720p recording/playback, lockscreens, custom lockscreens, pattern lock**, PIN**,PASSWORD**, SD and external SD mounting in-device and USB, SU and requests for SU, built-in PPTP VPN exept OpenVPN (others not tested yet), camera, gallery, certificates, sending of DTMF, ENDING CALL response time, receiving call response time, in call audio, speaker audio playback***, headset audio playback, lockscreen audio playback, IP calling, CIFS (via mount manager), Static IP, Wifi Hotspot, USB tethering, bluetooth call, system sensors****, battery usage, everything reported by Galnet.

Not working: everything known to Galnet.

* APN settings for Bell and possibly other networks, need to be edited to include port 80 for proxy port. Do NOT set this under system>proxy settings, but through system>mobile network settings>Access Point Names.

** Launcher settings may need to be set <disabled> in "keep in memory", then a reboot will be required, since app killer doesn't kill launcher. After which, all locks will work as intended even switching type of lock security. Note that pressing HOME button after entering lockcode will keep that application active and re-entering lock code(s) will not be required UNTIL the back button is pressed, successfully exiting the app from memory.

*** External audio volume adjustment seems low as a default. 1/4 setting is inaudible unless the speaker is next to the ear. Half volume seems to be what would be expected for 1/4 volume.

**** enable rotation to allow apps that require access to accelerometer.

If NEW problems arise that were not present before, then that is something entirely different and worthy to look into.

Galnet: Would it be easier and cleaner if you were to implement some protocols. Do you use trac? do you think it would be a better system to track bugs etc, than the current method you use? What about a script that verifies proper installation to your adherence? If someone finds a bug or an issue, this script can verify that they didn't make system changes that could potentially be the root cause of the problems they are having.