Testing application behavior in low memory conditions
In android, we can intercept the low memory event for our application or activity by setting it via registerComponentCallbacks as a handle to the heir from the ComponentCallbacks interface by overriding the onLowMemory method to it.
It is understood that in this handler, when a low memory event occurs, we must free non-critical resources, clean the internal cache and other methods to reduce the amount of memory used, thereby avoiding that our process will be closed.
The system also guarantees that after calling onLowMemory the system garbage collector will be called.
And so, if our application implements any behavior when this event occurs, it would be nice to test this behavior.
The standard way is simple - we begin to artificially increase the amount of resources consumed (for example, upload pictures twice) until we hit the limit.
And there is a second way - to change this limit, which, in fact, will be discussed below.
Unfortunately, this method will only work on rooted devices.
And so, the task scheduler in android divides running applications into 6 of the following types: For each of these types of applications there is a memory limit at which, if the memory remains less than this limit, the scheduler starts killing applications of this type that are not used from his point of view. These limits can be viewed as follows. For Samsung Galaxy Nexus, the values will be as follows
Values are measured in pages of memory, each page is 4 kilobytes.
If you have a rooted phone, you can change these values arbitrarily in real time, with a simple command.
When the device is rebooted, the values are restored.
And so, by changing these values in runtime you can easily call your onLowMemory handler, and also potentially test the behavior of the application on other devices on which these values are different (although this does not replace full testing on the device itself, of course).
It is understood that in this handler, when a low memory event occurs, we must free non-critical resources, clean the internal cache and other methods to reduce the amount of memory used, thereby avoiding that our process will be closed.
The system also guarantees that after calling onLowMemory the system garbage collector will be called.
And so, if our application implements any behavior when this event occurs, it would be nice to test this behavior.
The standard way is simple - we begin to artificially increase the amount of resources consumed (for example, upload pictures twice) until we hit the limit.
And there is a second way - to change this limit, which, in fact, will be discussed below.
Unfortunately, this method will only work on rooted devices.
And so, the task scheduler in android divides running applications into 6 of the following types: For each of these types of applications there is a memory limit at which, if the memory remains less than this limit, the scheduler starts killing applications of this type that are not used from his point of view. These limits can be viewed as follows. For Samsung Galaxy Nexus, the values will be as follows
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it! Value set in system/rootdir/init.rc on startup.
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear. Value set in
// system/rootdir/init.rc on startup.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned. Value set in
// system/rootdir/init.rc on startup.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption. Value set in
// system/rootdir/init.rc on startup.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go! Value set in system/rootdir/init.rc on startup.
// This value is initalized in the constructor, careful when refering to
// this static variable externally.adb shell cat /sys/module/lowmemorykiller/parameters/minfree7469,9396,11324,13372,15299,19034Values are measured in pages of memory, each page is 4 kilobytes.
If you have a rooted phone, you can change these values arbitrarily in real time, with a simple command.
echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfreeWhen the device is rebooted, the values are restored.
And so, by changing these values in runtime you can easily call your onLowMemory handler, and also potentially test the behavior of the application on other devices on which these values are different (although this does not replace full testing on the device itself, of course).