(Disclaimer: I am the co-founder of the company who developed the below tool)
We have a tool called LittleEye (http://www.littleeye.co) which does most of what you propose, but built for Android. Its a desktop tool that automatically injects an agent onto a connected phone. It can be used to monitor the power consumption of an individual application by modelling its power consumption based on the various hardware components its using (like CPU, display, GPS etc). If you are looking for an open source app which does something similar, checkout the research tool http://powertutor.org. It also does modelling of app power based on its hardware consumption. In addition to Wifi, 3G/4G power is also useful and there it has an additional complication of having tail states which are big concern with inefficient apps keeping the system awake all the time by doing period data transfers. Display power is also very useful (esp on OLED screens), and one can do that by sampling the screen periodically and looking at the various pixel values. Brightness of the screen is also a very useful factor. GPS is tricky because multiple apps could request for the location. In Android we differentiate between an app requesting for passive updates and active updates and if its in the foreground or background. The power is distributed based on all these factors. We are not too familiar with the FFOS, but would be happy to help if needed. :-) On Tuesday, June 11, 2013 6:59:03 AM UTC+5:30, Jonas Sicking wrote: > On Sun, Jun 9, 2013 at 8:42 PM, Vincent Chang(張藝馨) > > <changyihsin....com> wrote: > > > Hi there, > > > > > > As you may know that battery life has always been one of the important > > > concerns for users on > > > mobile devices. Our intern student Gavin Lai and I propose APIs and > > > framework on FFOS to help to > > > gather power consumption statistic information. Our goal is to provide > > > power consumption information > > > from gecko. The application can use these information to calculate the > > > power consumption per app. > > > > > > We classify the power consumption into two groups: > > > Application and System. > > > > > > For each application, there are several parts are included as follows: > > > 1. CPU > > > 2. WiFi Active (WiFi traffic) > > > 3. Radio Active (Radio traffic) > > > 4. Wakelock > > > > > > Some events or components are hard to distinguish into each app. > > > We classify this kind of power consumption into System. > > > 1. Screen > > > 2. WiFi On > > > 3. WiFi Scan > > > 4. Idle > > > 5. Bluetooth On > > > 6. Audio > > > 7. Video > > > 8. GPS > > > (Not sure)9. Bluetooth Active (Bluetooth traffic) > > > > As many of these as possible I think we should try to attribute to > > each app whenever possible. > > > > GPS in particular should be very possible to attribute to the > > particular app that is using it. We know whenever an app is requesting > > to get information from the GPS. We should divide GPS power > > consumption between any app that has requested location information > > within the last X seconds. > > > > Same thing should be possible to do for bluetooth I would imagine? > > > > In general I think we should work towards making the second list as > > short as we can. But it's something that we can do over time. But > > anything that turns out to be a high battery drain, we should > > prioritize to split it out per-app. > > > > Which brings up the point that it'd be great to add telemetry probes > > for each component. That way we will during dogfooding see which > > components use up a lot of battery. That allows us both to prioritize > > making them use less battery, when possible, and to prioritize logging > > the data per-app. > > > > / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
