Battery life has become the Achilles heel for the success of mobile software platforms, such as Android. The mileage users can get from their battery is severely impacted by software. Software implicitly and explicitly defines the power states of major system components when the phone is used and even when it is not used.

Just the LCD can consume as much power as the CPU in a mobile phone. A software power inefficiency or malfunction can quickly cause a drop of 5x in terms of standby time. Evidence for this is available in the user forums of all the major phone vendors where people have updated their phone with new firmware or applications.

Although power efficiency is a major quality and sign-off criteria for hardware platforms, it is still a poor cousin in the quality checklist for software. There are multiple reasons for this.

The software community still considers power as something that is taken care of by either hardware or the software layer they are building the functions on. Application developers trust that the application framework will make sure that while using services the underlying resources are used in a battery-friendly manner.

But the reality is that a simple RSS feed application that wakes up the phone every 10 minutes for just eight seconds to do some updates via the internet can cut the standby time of a phone in half. Software platforms for mobile applications must be engineered in such a way that smart heuristics make sure only those services required in the active usage scenario are provided. Components must be turned off when not in use.

When porting such platforms, the power control capabilities of the OS and their drivers must be made available to the application framework. During OS development and porting, software engineers have to make sure that all power saving features of the underlying hardware are leveraged and supported by drivers.

To read the full article go to:

System Level Software Centric Power Debugging using Virtual Prototypes