#For android download Precise CPU Stress code#
#For android download Precise CPU Stress free#

proc/meminfo file is part of proc file system which can be useful to get memory related information for a device at any instant.

#For android download Precise CPU Stress free#

It's basically a sum of low free and high free memory which are kernel-based and userspace-based memory respectively. MemFree value from the meminfo proc file is the unused memory in KBs at any time. The above shell script logs the free memory from the meminfo proc file into log_free_memory.txt file. Script log_memfree.sh with the following content: while :Īdb shell cat proc/meminfo | grep MemFree > log_free_memory.txt

#For android download Precise CPU Stress code#

We can configure the number of objects getting allocated by providing the number in intent extras as shown in the above code snippet.Ģ. This ADB command sends a broadcast to NativeAllocationReceiver.kt, which is responsible for calling a native method that allocates native objects. Script allocate_native.sh with the following content:Īdb shell am broadcast -a me._NATIVE -ei NUMBER_OF_OBJECTS 5 -p me.amanjeet.stressappĪDB command in the above snippet helps to allocate a number of native objects each of size ~42 MB approximately.Setupįor verifying that SIGABRT is generated, we have done the following setup in our sample app: You can verify whether SIGABRT is raised by doing a stress test on memory through the stressapptest tool. Requesting allocations of size larger than free memory while the system is on memory pressure can raise signal abort, a fatal native crash for your process. Observations through stressapptest SIGABRT due to low memory You can go through the internal documentation here. Stressful Application Test (or stressapptest) tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation. Use the following set of commands to push the static library in your data file system, make it executable and run a stress test for 20 seconds of 990 MBs adb push stressapptest /data/local/tmp/Īdb shell chmod 777 /data/local/tmp/stressapptestĪdb shell /data/local/tmp/stressapptest -s 20 -M 990 -C 8 You can push these static libraries via ADB and execute the stress test. I have created a forked structure of the original stressapptest in this repository which already has static libraries built for x86. You need to build for your test device architecture (x86, armv7, etc.). The tool is written in native and we need ndk-build from ndk for building this tool.

Together with this tool and instrumentation, you can verify any speculation that you have when your system goes into memory pressure. This tool helps you to define the time and memory size of the stress test. Stressapptest is one of the tools which can help you to reproduce memory pressure on any device. In this article, I will be introducing you to a tool that I found to be super useful for reproducing memory pressure conditions in any device. Recently, working on a similar issue I stumbled upon this use case where I wanted to increase the device memory pressure and verify one of the native crashes in the app.

Reproducing such memory stress conditions will help you write any instrumentation to verify the behavior of your app in memory pressure conditions and also to empathize with the users when the memory pressure occurs and the device and process start to throttle. The biggest problem in analyzing any issue related to high memory pressure is to be able to reproduce such memory pressure conditions in your local test device farms.

You can create observability on such issues around the killing of your processes in android by tracking TRIM_MEMORY_EVENTS by overriding the onTrimMemory method in your application class. You can look at your app score in the proc file system path: /proc//oom_adj_score. Processes with a high score are killed first. LMKD assigns a oom_adj_score to each process which helps it to prioritize running processes. LMKD (Lower memory killer daemon) is responsible for killing processes to reclaim memory in case the system memory goes down. Native heap on the other hand has lesser restrictions and is not garbage collected by GC, which can risk the process if memory is not managed properly on the native side.

Exceeding this limit leads to an out-of-memory exception even on high-end devices. Here, the memory stress we are discussing is not related to java allocations since the java heap has a limit on the allocations for a particular process. Your chances of stumbling upon memory stress issues increase when a large number of users on your app are on low-end devices. Memory stress issues are less common in android as devices nowadays have considerably higher RAM.