[G1 Android Development] farmatito:
I did a little research on the internet about the cpu frequency and battery life issue

and have found some interesting infos on:

http://mjg59.livejournal.com/88608.html

The problem is that nowadays, processors don't consume as much
energy when they're idle as when they're running. The aforementioned C states
mean that an idle processor consumes a tiny percentage of a loaded one - an
ultra-low voltage Intel part will draw on the order of a watt. Executing code,
even at the lowest voltage and frequency, will draw far more power. Obviously,
we want to keep the processor idle for as long as possible. The easiest way to do
this would be to never run anything, but that's not a real option. The alternative
is to run when we have to, but make sure that we get it over with as quickly as
possible so we can return to the idle state. Counterintuitively, that means
switching to the highest voltage and frequency, executing the code and then
dropping back into the idle state. By going faster, we save power[3].

This could eventually explain our issue and rather than look at the battery stats

we should look at the top command (included in busybox) to see the amount of

cpu idle time obtained with different cpu frequencies.

The top program provides a dynamic real-time view of a running system.
It can display system summary information as well as a list of tasks currently
being managed by the Linux kernel.
The top command monitors CPU utilization, process statistics, and memory
utilization. The top section contains information related to overall system status:
uptime, load average, process counts, CPU status, and utilization statistics for
both memory and swap space.

Mem: 96008K used, 1860K free, 0K shrd, 360K buff, 24648K cached
CPU: 0.7% usr 0.7% sys 0.0% nic 98.4% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.00 0.19 0.80 1/233 484
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
56 1 root S 3332 3.4 0 0.7 /sbin/adbd
407 173 10037 S 92540 94.3 0 0.3 com.smartandroidapps.audiowidget
194 173 system S 146m153.3 0 0.2 system_server
484 472 root R 1824 1.8 0 0.2 top
235 173 10006 S 113m118.3 0 0.0 android.process.acore
456 173 10057 S 108m113.2 0 0.0 com.htc.android.htcime
229 173 radio S 106m111.6 0 0.0 com.android.phone
272 173 10007 S 104m109.2 0 0.0 com.google.process.gapps
347 173 10010 S 97372 99.2 0 0.0 com.android.calendar
320 173 10027 S 97124 99.0 0 0.0 android.process.im
380 173 system S 96440 98.3 0 0.0 com.android.settings
369 173 10065 S 95780 97.6 0 0.0 com.fsck.k9
283 173 10036 S 95108 96.9 0 0.0 android.process.media
261 173 10012 S 94948 96.7 0 0.0 com.android.mms
389 173 10009 S 94332 96.1 0 0.0 com.android.music
415 173 10022 S 94200 96.0 0 0.0 com.google.android.gm
399 173 10039 S 93356 95.1 0 0.0 nl.jsource.retroclock.android
359 173 10020 S 92792 94.5 0 0.0 com.android.alarmclock
312 173 10033 S 92404 94.1 0 0.0 com.android.voicedialer
173 1 root S 72028 73.4 0 0.0 zygote /bin/app_process -Xzygote /

I've changed scaling_min_freq for test purposes in my userinit.sh

echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

and top shows now 98,4% idle time.

More research needed. Contributions and hints are welcome.