Application Resource Monitor added to BlackBerry 7.1


Upcoming versions of BlackBerry® Device Software version 7.1.0.x introduce a new service that monitors BlackBerry® applications for system resource abuse, which could cause accelerated battery depletion. This service is called Application Resource Monitor. An optional feature (enabled by default) is available to automatically shutdown background battery draining applications.

Image By Civilspanaren (Own work) [Public domain], via Wikimedia Commons

What It Does

BlackBerry Application Resource Monitor monitors applications when they are in the background (with the screen on or off) and when in the foreground when the screen is off. When the app is in one of these two states, it looks for excessive background wakeups (any sort of timers firing including rapid/constant repaints) and high CPU utilization.

When efficient applications are in these two states, they should not be consuming an excessive amount of CPU or exhibiting any sort of timer abuse. When the problematic application is identified, an alert may be presented to the user. If “Automatically shutdown background draining applications” is enabled, the user is alerted and the application is shut down. If it is disabled, the user is alerted and they have the ability to close the app from within the notification. The ability to automatically shut down background-draining applications can be enabled and disabled within the Application Resource Monitor options access on a BlackBerry® smartphone by going to Options -> Device > Application Resource Monitor. The default setting is for it to be enabled.

Applications can also be whitelisted so that they are not shut down by Application Resource Monitor. To whitelist an application, users need to first receive an alert. If the ability to automatically shut down background-draining applications is disabled, they are simply alerted about the problematic application. They can acknowledge the alert (OK), whitelist the app (Ignore Future Alerts) or choose to manually shutdown the app (Kill it Themselves). If it is enabled, the application will be shut down and an alert presented to the user. The user can then open the alert to acknowledge and dismiss it, or whitelist the application to ignore this application going forward. To remove items from the whitelist, users can go to Options > Device > Application Resource Monitor.

How to Avoid Being Shut Down

You can prevent your application from being shut down by Application Resource Monitor by detecting and adapting to the state changes described above. If we use the example of a game, you can put your game into a paused state where it is not making any game play calculations for things like physics or artificial intelligence, and so it is not refreshing the screen when the game has moved to the background or when the screen has turned off.

Detect Moving to the Background

There are two ways to detect that your application is no longer in the foreground. Application.deactivate() is called when an application is moved to the background, and Application.activate() is called when the application moves to the foreground. Override both of these methods to detect the backgrounding and foregrounding events.

An application screen can override the Screen.onObscured() method to be notified when another screen appears on top of it, which may or may not be another application. This method is fired when the menu appears or if a dialog from your application is shown, which could be another point where you would want to pause your game. Screen.onExposed() is the matching method that is fired when screens on top of your application have been removed and your screen moves to the top-most position on the screen stack.

Detect the Screen Turning Off and On

There are also two ways to detect the BlackBerry device screen turning on or off. You can use the SystemListener2.backlightStateChange(boolean on) interface to be notified when the screen turns on or off. The Backlight.enabled() method can be used to poll for the current state of the screen.

Handling the Shutdown Request Gracefully

Overriding Application.requestClose() can allow your application to respond gracefully to a termination request. Returning true from this method will allow your application 10 seconds to process any required cleanup before it is shut down. Returning false will shut down the application immediately. This can also be used for diagnostic purposes, as it can log information about the state of the application for debugging purposes. Be careful to avoid logging excessive amounts of data in the production version of your application. requestClose is also fired for visible applications (those for which acceptsForeground() returns true) if they have not been used for one hour, regardless of whether or not they are using background timers or significant CPU. (However, applications are not terminated after being idle for one hour. This is simply a suggestion that they could close to conserve resources.)

Application termination from Application Resource Monitor is not limited to visible applications – in fact, it’s arguably more important that non-visible processes are terminated since users are not otherwise able to easily shut them down. You should consider the possibility that their processes may be shut down and ensure that this does not hinder future use of your app.

Verifying Efficiency using the BlackBerry Java Plug-in for Eclipse

Efficient applications that already take into account the states described above should not be impacted. However, it makes sense to do some performance testing of your application to verify that it does act like a good citizen. A new view has been added to version 1.5.2 of the BlackBerry Java® Plug-in for Eclipse™ that allows you to do just that. The new Process View allows you to monitor CPU utilization of your application, where you can monitor the statistics presented to observe the impact of your application while it is in the background and/or when the screen has turned off.

BlackBerry Java Plug-in for Eclipse Profiler View

How to Determine if an Application was Shut Down by Application Resource Monitor

Application Resource Monitor will create an entry in the event log every time it shuts down an application. You can view the event log on a BlackBerry smartphone from the home screen by holding down the Alt key and pressing LGLG. You can also extract it using the javaloader command line tool (javaloader –u eventlog > mylog.txt).
Application Resource Monitor will log detailed information about why the application was shut down and how it handled the shutdown request. Stack traces may be useful if the alert stems from processing too many timer events in the event handling thread (usually from the use of invokeLater with timed runnables and very short timeouts), but it’s more likely that the stack trace won’t capture the specific event processing at the time of the trace dump.

Setting the minimum event log level to “information” will provide more information about background activity that doesn’t meet the criteria to trigger notification or automatic shutdown – i.e. background timer activity below the minimum wakeup rate threshold. Here is a sample event log entry that shows an application being shut down by Application Resource Monitor, with comments added describing the entries shown bolded in red:

W 22:01:02 – net.rim.appmon – Terminating still-running process TestWebworks(596) Logged because the app did not support requestClose()

W 22:01:01 – net.rim.appmon – Shutting down process automatically Logged because autokill is enabled.

W 22:01:01 – net.rim.appmon – Thread CPU r=0, t=47085 Recent (last 2 seconds) and cumulative CPU time (ms) for the thread with the preceding stack trace

a 22:01:01 – Java Exception – ForcedStackTraceException Start of stack trace of a single thread in the process.

| VM:AppM TestWebworks(596) 322 2 0x15580800
| net_rim_cldc(4FA2F16A)
| Object
| wait
| 0xA7AF
| net_rim_cldc-36(4FA2F16A)
| MessageQueue
| dequeue
| 0x72F5
| net_rim_cldc-11(4FA2F16A)
| ApplicationProcess
| getMessage
| 0x4A6E
| net_rim_cldc-10(4FA2F16A)
| Application
| processNextMessage
| 0x2249
| net_rim_cldc-10(4FA2F16A)
| Application
| enterEventDispatcher
| 0x2196
| TestWebworks-2(4F9144A8)
| Widget
| main
| 0x741C

W 22:01:01 – net.rim.appmon – Thread CPU r=0, t=9531

a 22:01:01 – Java Exception – ForcedStackTraceException

| VM:AppM TestWebworks(596) 173 3
| TestWebworks-3(4F9144A8)
| AnimatedGIFField$AnimatorThread
| run
| 0x187

W 22:01:00 – net.rim.appmon – Thread CPU r=0, t=125632

a 22:01:00 – Java Exception – ForcedStackTraceException

| VM:AppM TestWebworks(596) 163 3
| TestWebworks-2(4F9144A8)
| MemoryMaid
| run
| 0x3081

W 22:01:00 – net.rim.appmon – Thread CPU r=0, t=242

a 22:01:00 – Java Exception – ForcedStackTraceException

| VM:AppM TestWebworks(596) 352 2 0x14FE2C00
| net_rim_cldc(4FA2F16A)
| Object
| wait
| 0xA7AF
| TestWebworks-2(4F9144A8)
| EventQueue
| dequeueWaitIfEmpty
| 0x25FB
| TestWebworks-2(4F9144A8)
| SystemEventManager
| getNextWaitingEvent
| 0x600D
| TestWebworks-2(4F9144A8)
| SystemEventExtension
| invoke
| 0x5E09
| TestWebworks-3(4F9144A8)
| WidgetRequestController
| handleResourceRequest
| 0x4DA0
| net_rim_bb_browser_field2_api(4FA2F821)
| RenderingApplicationImpl
| getInputConnectionDirect
| 0x3971
| net_rim_bb_browser_field2_api(4FA2F821)
| RenderingApplicationImpl$2
| run
| 0x3D0D
| net_rim_bb_apps_framework-4(4FA2F73D)
| Job
| go
| 0x4874
| net_rim_bb_apps_framework-4(4FA2F73D)
| Worker
| joinableRun
| 0xA682
| net_rim_cldc-34(4FA2F16A)
| InterruptibleThread
| run
| 0x1EEE

W 22:01:00 – net.rim.appmon – Thread CPU r=0, t=0

a 22:01:00 – Java Exception – ForcedStackTraceException

| VM:AppM TestWebworks(596) 330 2 0x258AC400
| net_rim_cldc(4FA2F16A)
| Object
| wait
| 0xA7AF
| TestWebworks-2(4F9144A8)
| PushListener2$MessageProcessor
| run
| 0x44EA

W 22:01:00 – net.rim.appmon – Process TestWebworks(596), system = false, visible = true, localized app name = BARM Test App, group name = RIM, friendly group name = BARM Test App Details about the process.

W 22:01:00 – net.rim.appmon – Process TestWebworks(596) background wakeup count 3661 over 420023ms First log for the alert, shows the wakeup rate.

Triggering Application Resource Monitor Shut Down for Application Testing

The BlackBerry Profiler View in the BlackBerry Java Plug-in for Eclipse should always be the first tool you use to test and enhance the efficiency of your application. However, you may want to test how your application behaves in the event that it gets shut down by Application Resource Monitor. To do so, you can lower the thresholds that it uses to determine if an application should be shut down. This can also be used in conjunction with the BlackBerry Profiler View to ensure that your application stays well under the default threshold. To modify this threshold, go to Options -> Application Resource Monitor on your BlackBerry smartphone, then type FLTR to display the additional options. You should see a screen that has these additional options:

Here are some tips on how to configure these settings while testing your application.

  • Reduce the wakeup threshold to a low level, perhaps the minimum. It is intentionally set at a very conservative (high) level by default.
  • Disable automatic shut down – this allows you to immediately profile the application when Application Resource Monitor triggers an alert and before changing the state, to see what’s going on in your application.
  • Disable transient filtering – this will speed up detection of sustained problems.
  • If you are performing very frequent restarts of your BlackBerry smartphone while testing, reduce the startup delay to 0.

Shutting Down

The BlackBerry Application Resource Monitor is designed to help consumers get the most battery life out of their BlackBerry smartphone by closing applications that are abusing resources leading to noticeable battery drain. By following the steps outlined in this article, you can ensure that your application behaves like a good citizen on the device and is never noticed by Application Resource Monitor.

Join the conversation

Show comments Hide comments
+ -