Mobile devices that are left idle can quickly fall asleep to save energy. Android wake lock mechanism allows developers to specify the need of keeping certain device hardware awake to run long-running tasks (e.g., large file downloading).
To use a wake lock, developers need to write the following code to specify the lock type and certain flags (see Android API guide):
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, "My Tag");
wl.acquire();
..screen will stay on during this section..
wl.release();
In the early days, Android supports quite a few types of wake locks:
Type | CPU | Screen | Keyboard |
---|---|---|---|
partial wake lock | on | off | off |
screen dim wake lock | on | dim | off |
screen bright wake lock | on | bright | off |
full wake lock | on | bright | bright |
As the platform evolves, the full and screen wake locks are deprecated. To keep screen awake, Google suggests using the FLAG_KEEP_SCREEN_ON
in activities:
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
}
or declare the android:keepScreenOn
attribute in the application layout XML files:
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:keepScreenOn="true">
...
</RelativeLayout>
Then the system will manage the screen status according to the lifecycle of activity components (screen will be kept on when the activities are visible). This eases app development and avoids mistakes in wake lock uses.
In our recent research paper, we studied the real uses of wake locks by analyzing 44,736 Android apps (download). In particular, we studied the following research questions:
We made quite a few important findings
. We discuss some examples here. Full findings available in our paper and technical report.
Networking & Communications | Logging & file I/O | Asynchronous computation |
UI & graphics rendering | Inter-component communication | Data management & sharing |
System-level operations | Media & audio | Security & privacy |
Sensing operations | Alarm & notifications | System setting |
Telephony services |
We also observed eight common patterns of wake lock misuses
. Details and examples are provided in our paper.
Unnecessary wake up
: wake locks are acquired too early or released too late. Consequence: energy waste.Wake lock leakage
: acquired wake locks are forgotten to be released. Consequence: energy waste.Premature lock releasing
: wake locks are released before being acquired. Consequence: app crash.Multiple lock acquisition
: wake locks are acquired too many times (e.g., when the acquiring operation resides in a frequently-invoked callback), exceeding the limit allowed by Android OS. Consequence: app crash.Inappropriate lock type
: using a wake lock with a wake level that is too high may waste energy, while using a wake lock with a wake level that is too low may cause app instability.Problematic timeout setting
: using wake locks with a too long timeout value may waste energy, while using wake locks with a too short timeout value may cause app instability.Inappropriate flags
: wake lock flags also need to be carefully set. Using Inappropriate flags (e.g., ON_AFTER_RELEASE) can cause energy waste.Permission error
: using wake locks without obtaining the WAKE_LOCK permission will crash an app.To detect wake locks misuses, we also designed a static analysis tool Elite, which performs data flow analysis to infer an app’s necessity of using wake locks. If you are interested, try our prototype.
Comments Section