share article

Share on facebook
Share on twitter
Share on linkedin

Optimising the Android platform for power efficiency


By Hani Tawfiq Khader and Shabbir Majeed Chaudhry, University of Engineering and Technology, Taxila, Pakistan

Android is a very popular operating system (OS), and because of its effectiveness, performance and practicality, it is widely used in mobile and portable devices. However, its popularity has also brought it a drawback in the form of poor optimisation since some vendors do not build it but port it from stock, such as Android Google sources. Often, this results in the hardware’s lower performance and poor power efficiency.

Optimising the OS

Optimising an operating system consist of re-writing or modifying the main source code, whilst taking into consideration each system’s unique set of parameters. With Android, using the source code is not entirely possible in most cases, since many companies that provide Android devices keep their systems closed. Still, most of these systems are built using the main source code.

Having prior knowledge of the OS and its modifications helps further optimise it, by providing direct solutions to challenges encountered on any device built on it. This sort of re-optimisation can be carried out without having to decompile the original sources of the Android OS, and also it can be done at the user’s end.

Improving the power efficiency of the Android platform is one of the most active research areas in Android system development. Different research studies have been carried out on existing techniques to improve battery efficiency without compromising user experience, including ways of lowering screen brightness, switching pixels, increasing Screen-On Time (SOT), using alternative applications that do same work with less resources, and others.

Google introduced a method that provides a better battery efficiency by restricting app access to network- and CPU-intensive services. Also, there’s a method of increasing battery efficiency by determining and monitoring device connectivity status; for example, if not connected to the Internet, the device will not need a scheduled update either.

During design, first we need to establish the main areas that affect the system’s optimisation and efficiency, including:

  • User applications and services;
  • Memory;
  • Network optimisation;
  • Kernel optimisation.

Lowering the Energy Consumption

User applications and services consume power, since they constantly use background processing (CPU, GPU, etc.), synchronisation, data transfer to and from the Internet and communications protocols among others. App hibernation helps increase device efficiency to over 75%; however, it’s best that hibernation entirely stops the app’s background processes, with only a gap or a wakeup timer for device wake-up; this gap can work as a periodic CPU wake-up timer for the app. Table 1 shows battery usage in different operating modes.

Table 1. App hibernation efficiency

Another way to improve app efficiency is by automating its tasks. We used Tasker for a test case, with which we automated several apps that normally run all the time in the background. The goal was to place these applications in hibernation mode as soon as the user turns off the screen. Once the screen comes back on, the applications start to run again.

Fig. 1 Display state

After testing the automation of the most-used applications like WhatsApp, Facebook, Twitter, etc., on the display state task for 24 hours, the automation saved over 25% of standby time without compromising user experience.

Fig. 2 Hibernation application comparison chart

Memory Management

Improved memory management also optimises the system, which affects both performance and battery use. We tested something called ‘Swappiness’ on the memory to ascertain how it may increase battery consumption rate, considering the size of the RAM (Random Access Memory). Swappiness is a property of the Linux kernel that changes the balance between swapping out runtime memory, as opposed to dropping pages from the system page cache. Swappiness can be set to values between 0 and 100; a low value means the kernel will avoid swapping as long as possible, whereas a higher value will make the kernel work harder to use swap space.

We set Swappiness to 60 to start with, which keeps the swap in an on-state whenever the RAM is 35-40% used. This results in a slower task operation, which decreases efficiency.

In a follow-up test, we reduced the Swappiness value to 25 on a 3GB RAM device, which makes the swap work only after 70-75% of RAM is used:

chmod 644 /proc/sys/vm/swappiness
echo “25” > /proc/sys/vm/swappiness

Above, the ‘/proc/sys/vm/swappiness’ parameter sets the value that balances between dropping pages from page cache and the swapping-process memory.

Other parts of the memory are ‘dirty_writeback_centisecs’ and ‘dirty_expire_centisecs’, where the first refers to how often the kernel flusher threads will wake up to write dirty data to disk, and the latter is how long data can be in cache before it needs to be written. Default values are five seconds for ‘dirty_writeback_centisecs’ and 30 seconds for ‘dirty_expire_centisecs’. We rearranged the timing by doubling the value of ‘dirty_writeback_centisecs’ to 10 seconds and at the same time decreased the ‘dirty_expire_centisecs’ to five seconds:

if [ -e /proc/sys/vm/dirty_expire_centisecs ]; then            
echo “500” > /proc/sys/vm/dirty_expire_centisecs
if [ -e /proc/sys/vm/dirty_writeback_centisecs ]; then            
echo “1000” > /proc/sys/vm/dirty_writeback_centisecs

‘/proc/sys/vm/dirty_expire_centisecs’ and ‘/proc/sys/vm/dirty_writeback_centisecs’ are stock kernel parameters that set the value of both ‘dirty_expire_centisecs’ and ‘dirty_writeback_centisecs’, respectively. Setting these improves RAM management, which enhances the memory task performance and eliminates any delays in task processing. At the same time, battery performance was improved by 15-20%.

Fig. 3 Memory effects on a full battery cycle

Network Optimisation

Wi-Fi is one of the most common reasons for low battery performance. The constant usage of the Wi-Fi service relies on Wi-Fi wakelocks, which keep the devices awake for app access, preventing it from going into deep sleep, and hence causing rapid battery-drain. It’s most effective to run the Wi-Fi service when needed, which will reduce the wakelock service by over 80%.

We can modify the SQlite database of the device settings parameter ‘Android ID’ located in the ‘/data/data/’ by using the Bash (Unix shell) language:


RETURN_VALUE=$($sqlite /data/data/ “select value from secure where name=‘wifi_idle_ms’”)  

if [ $RETURN_VALUE=‘‘ ]; then  $sqlite /data/data/ “insert into secure (name, value) values (‘wifi_idle_ms’, $wifi_idle_wait )”
$sqlite /data/data/ “update secure set value=$wifi_idle_wait where name=‘wifi_idle_ms’” Fi

‘Wifi_idle_ms’ is a parameter that controls Wi-Fi idle time for the default sleep policy from the Android Open Source Project. This script allows to set the value of ‘wifi_idle_ms’ to a specific time. Once the screen is turned off, Wi-Fi remains connected for 60 seconds before it turns off; 60 seconds is the value we assigned to the variable ‘wifi_idle_wait’. Once the screen is on, Wi-Fi automatically reconnects. This resolves most wakelock issues related to Wi-Fi. As an alternative solution to network connection loss, when the screen is off, the device can automatically connect to data connection of the SIM card, turning off Wi-Fi.

We conducted a worst-case scenario test on a device running on the Android platform 5.1.1, connected to a public Wi-Fi access point, a public university campus where many people use the service, which lowers the connection quality. We conducted the test over two days; see Table 2.

Day Standby Time Screen on Time
1 6h 1.3h
2 24h 6.8h
Efficiency Difference 300% 423%

Table 2. Test case: University campus Wi-Fi sleep efficiency

The first day the device was connected to the Wi-Fi access point with standard settings, and the second, the device was connected to the access point using settings with the Bash script. The ‘wlan_rx wakelock’ lowered its operation from 85% of the time to 8%, in one battery cycle.

Fig. 4 Wi-Fi connected at the university campus with standard Android 5.1.1 settings

Fig. 5 Wi-Fi connected at the university campus with settings using Bash script

In Figure 4, ‘wlan_rx_wake’ was awake 85% of the time during the last five hours (after unplugging the charger), leaving the battery with 54% capacity.

In Figure 5, after using the script to put the Wi-Fi to sleep (60 seconds after turning the screen off), the ‘wakelock_rx_wake’ was awake for only 50 minutes and 49 seconds, which is 8% of the time, leaving the battery with 80% capacity after 10 hours and 55 minutes following unplugging the charger.

We repeated the test in a residential house with Wi-Fi access point; see Table 3.

Day Standby Time Screen on Time
1 17h 3h
2 38h 3.2h
Efficiency Difference 55.26% 6.25%

Table 3. Test case: Wi-Fi sleep efficiency in a residential home

The standby time was enhanced by 55.26%, while screen usage was almost the same, in a full battery cycle, due to the absence of Wi-Fi connectivity in the background when the screen was off or in standby.

Fig. 6 Wi-Fi test at different locations

Bluetooth Power Consumption

The Bluetooth service is also one of the most common power users. The service usually handles data transfer or pairing with another device. Since most users forget to toggle off the Bluetooth service after using it, this results in a significant battery drain.

One of the solutions we propose is to have the Bluetooth service turned off automatically when not paired with a device for a specific period of time. To implement it, we created a Tasker profile that checks if the Bluetooth status is on and not paired with any device, and following a two-minute delay, Bluetooth turns off; see Figure 7.

Fig. 7 Bluetooth connection status

In some cases, we were unable to trigger the Bluetooth toggle through Tasker alone, so we created an alternative solution. Using Android Open Source Code for Bluetooth and Bluetooth Adapter, we wrote a simple Bluetooth application in the Java programming language with API level 5, with which the Bluetooth service can then be toggled off through Tasker or any other automation app:

package hani.bluetooth;  

import android.annotation.TargetApi;
import android.bluetooth.BluetoothAdapter;
import android.bluetooth.BluetoothDevice;
import android.content.Intent;
import android.os.Build;
import android.os.Bundle;
import android.widget.TextView;
import android.widget.Toast;    

public class MainActivity extends AppCompatActivity {    

private BluetoothAdapter btAdapter;    

protected void onCreate(Bundle savedInstanceState) {  
TextView btStatus = (TextView) findViewById(;  
btAdapter = BluetoothAdapter.getDefaultAdapter();    

if (btAdapter.isEnabled()) {  
Toast.makeText(getApplicationContext(),”Your Bluetooth has been turned off”, Toast.LENGTH_LONG).show();}  
else{ Toast.makeText(getApplicationContext(),”Something went wrong! Unable to turn off Bluetooth.”, Toast.LENGTH_LONG).show();}  
this.finishAffinity();  }    
else {  
btStatus.setText(“Your Bluetooth interface is currently off”);  }    


This solution saves a lot of power lost to useless connections of the Bluetooth service, and improves overall system efficiency.

We then tested the solution. Results showed that a high number of Bluetooth wakelocks were present when the toggle was on, even though Bluetooth was not in use; see Figure 8. Figure 9 shows the level of wakelocks present when the device was in standby, and how deep sleep was interrupted by them. This resulted in a stressful power drain from 85% down to 77% in 6.5 hours in standby. Figure 10 shows the low level of wakelocks on the same device after turning off the Bluetooth toggle, which resulted in a power drain of 96% to 95% in a seven-hour standby state.

Fig. 8 Wakelock management

Fig. 9 Bluetooth connected and not paired

Fig. 10 Bluetooth toggle off

Kernel Optimisation

We developed a kernel optimisation routine based on Samsung Sources for Exynos 5433, which has shown a significant improvement regarding power efficiency. One of the most significant changes that helped saving power was introducing a WQ_POWER_EFFICIENT flag. Adding the flag as a system-wide workqueue reduced standby battery drain and improved deep sleep. Furthermore, we reduced the ‘wakelock_rx and wakelock_ctrl’ wakelocks of Broadcom Dongle Host Driver from Android Open Source by adding a variable and dividing it by the original value of the wakelocks’ timeout:

#ifdef CONFIG_HAS_WAKELOCK            
if (dhd->wakelock_rx_timeout_enable)                        
if (dhd->wakelock_ctrl_timeout_enable)                        

The same concept can also be applied on other wakelocks.

For GPS:

wake_lock_timeout(&g_bport->bcm4773_wake_lock, HZ/wl_divide_gps);

For motion sensors:

wake_lock_timeout(&data->ssp_wake_lock, wl_motion * HZ);

For a proximity sensor:

wake_lock_timeout(&data->ssp_wake_lock, wl_prox * HZ);

For a temperature sensor:

wake_lock_timeout(&data->ssp_wake_lock, wl_temp * HZ);

Wakelocks timeout can be decreased to achieve higher power efficiency without affecting user experience. For instance, setting the value of wl_divide = 4 will give 1/4th of the timeout for the Wi-Fi wakelocks. Other wakelocks like GPS and sensor wakelocks can also be optimised by giving a smaller window gap at which the wakelock do checks. This significantly improves power efficiency when using these services.

Figure 11: Before using WQ_POWER_EFFICIENT flag and reducing wakelocks by kernel

Fig.12 After using WQ_POWER_EFFICIENT flag and reducing wakelocks by kernel

In Figure 11, when the device was in off-charger state (unplugged), the battery’s full cycle was 11 hours, with 2.5 hours Screen-On-Time. Wakelocks are shown active in many time intervals of ‘Awake’ when the screen was off, which affected the deep-sleep state and kept the device active.

In Figure 12, when the device was in off-charger state (unplugged), the battery’s full cycle was one day, 10 hours and 49 minutes, with 3.83 hours Screen-On-Time. This significant improvement in power efficiency proves how kernel optimisation plays a major role when creating an efficient power system.


These methods were developed to be interactive and flexible for the developer and user alike, which progressively defines the best way to overcome low efficiency issues on any Android platform. These methods can be applied to any Android system, in particular Lollipop 5.1.1 and previous versions.

The tests we carried out show that for common problems that affect device performance, an exact solution is found that can fine-tune both performance and battery consumption. As to effectiveness, these methods were tested by an Android development testing team, who judged the overall result to be practical and efficient. Most of the differences in general raw performance we re-evaluated as improvements over the stock system.

In general, the trade-off between the power efficiency and the stability of the re-optimised system is always very good. For these reasons, these optimisation methods could be a very convenient and powerful add-on to existing software for Android development.

Share this article

Share on facebook
Share on twitter
Share on linkedin

Related Posts

View Latest Magazine

Subscribe today

Member Login