Develop Reference

What is EGL and GL mtrack in Android Memory Dump

I'm currently working on a hybrid application that is exhibiting some peculiar memory usage that I'm trying to debug. As soon as the application starts, it appears to be immediately using close to 250MB of memory, which seems excessively given that all we have loaded at that point is the login screen. I've been looking at a few memory profiling tools for Android (the Xamarin profiler and the android profiler shipped with the SDK), but all of them show relatively low heap usage (~10-15MB, which I'm trying to get down). I ran "adb shell dumpsys meminfo APPNAME -d' and got the following trace:
** MEMINFO in pid 24925 [APPNAME] **
Pss Private Private Swapped Heap Heap Heap
Total Dirty Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------
Native Heap 19439 19396 0 0 28672 22915 5756
Dalvik Heap 15441 14992 0 0 37319 36837 482
Dalvik Other 542 368 0 0
Stack 432 432 0 0
Ashmem 17388 16508 880 0
Gfx dev 40538 34504 0 0
Other dev 4 0 4 0
.so mmap 6211 224 3080 0
.apk mmap 10531 0 10232 0
.ttf mmap 453 0 260 0
.dex mmap 1263 0 980 0
.oat mmap 635 0 152 0
.art mmap 707 516 24 0
Other mmap 452 4 52 0
EGL mtrack 63508 63508 0 0
GL mtrack 79116 79116 0 0
Unknown 21756 21756 0 0
TOTAL 278416 251324 15664 0 65991 59752 6238
I've been trying to understand what this means by using the documentation provided at: https://developer.android.com/tools/debugging/debugging-memory.html, but that page doesn't seem to have any info on the biggest culprits: Gfx dev, EGL mtrack, GL mtrack, and Unknown. Is there some documentation on what these categories are or why they would grow to be so big?
Thanks

EGL and GL shows here memory consumed by Graphics layer basically. I am sure you are running adb shell dumpsys meminfo command on Android lollipop device. Actually dumpsys meminfo tool/command has been modified in lollipop to calculate and display graphics memory.
In old version (KitKat or older) you can not find EGL and GL information although graphics consumed memory in KitKat or older versions also.
This is we can request Google to update their documentation to explain new memory components also. In short you can say it is bug in documentation of Android. They should update it as per latest implementation of adb shell dumpsys meminfo tool/command.
References:
EGL - http://en.wikipedia.org/wiki/EGL_(API)
GL - http://en.wikipedia.org/wiki/OpenGL

GL mtrack is driver-reported GL memory usage. It's primarily the sum of GL texture sizes, GL command buffers, fixed global driver RAM overheads, etc.
EGL mtrack is gralloc memory usage. It's primarily the sum of the SurfaceView/TextureView.

query about "dumpsys meminfo" in android

When I run "adb shell dumpsys meminfo" on android 4.2, I get the result like
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 28 8 28 16404 12256 3663
Dalvik 14062 10060 13736 20032 15254 4778
Cursor 0 0 0
Ashmem 0 0 0
Other dev 4762 9556 0
.so mmap 11699 1824 1500
.jar mmap 0 0 0
.apk mmap 368 0 0
.ttf mmap 811 0 0
.dex mmap 3736 0 0
Other mmap 114 16 32
Unknown 12064 544 12052
TOTAL 47644 22008 27348 36436 27510 8441
I have read the page of How do I discover memory usage of my application in Android?, but still have several questions:
Why the native Pss, shared dirty private dirty is very small?
the heap size should be smaller than Pss?
What does Unknown mean? Seems very big.
If I want to know how much memory my app uses, which data should I use? The Total Pss? But it doesn't include the native Pss which is nealy zero?

Please refer to the question How do I discover memory usage of my application in Android?.
I would also like you to refer to Detail VSS,RSS,PSS,USS link. The most appropriate data to use for a particular app is
USS (Unique Set Size ) as
USS is the total private memory for a process, i.e. that memory that is completely unique to that process . USS is an extremely useful number because it indicates the true incremental cost of running a particular process. When a process is killed, the USS is the total memory that is actually returned to the system. USS is the best number to watch when initially suspicious of memory leaks in a process.
which you can get by adb shell procrank | grep <your.package.name>

How get per core cpu usage on Android / Galaxy SIII

I've a Samsung Galaxy SIII with Android 4.1.2 "rooted". I need to measure the CPU usage for some multithreaded applications I've written in C/C++, however I need this information in a per core basis.
I know (due wikipedia, ...) that the Galaxy has a SoC with 4 ARM Cortex A9 however when I do a cat /proc/cpuinfo it doesn't show any information regarding the number of available cores (as usual in any Linux), is this correct behavior?
I've read somewhere that I can use cat /proc/stat to see the per core load average however, in my device, the content of such "file" only shows information for the "core0", again, is this correct or do I need to do something to enable all cores?
I also tried with top and ps without success.
EDITED:
----------------- cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 1592.52
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0
Chip revision : 0011
Hardware : SMDK4x12
Revision : 000c
Serial : 11e16f694df1267e
----------------- cat /proc/stat
cpu 89515 1686 23283 464122 3835 2 376 0 0 0
cpu0 74214 457 16736 221609 1111 1 347 0 0 0
intr 1860068 0 0 0 0 0 0 0 0 0 0 .... (removed: a serie of numbers)
ctxt 3138146
btime 1371578546
processes 15904
procs_running 1
procs_blocked 0
softirq 1154788 12 403499 864 4501 12 12 444746 67202 576 233364

You can get information about the number of cores by examining the hotplug devices, /sys/devices/system/cpu/present and /sys/devices/system/cpu/possible. See also the hotplug docs.
I'm not sure this helps you much as far as getting CPU usage. You can get a crude sense for how much user and system time a thread has used from adb shell ps -x -t, e.g.:
USER PID PPID VSIZE RSS WCHAN PC NAME
system 19598 19574 955672 57324 ffffffff 4012d9b8 S system_server (u:2186, s:1521)
system 19602 19598 955672 57324 c007f840 4012db84 S GC (u:79, s:6)
This says that system_server's main thread has used 2186 ticks of user time, while the GC thread has used 79 ticks.
If you can instrument your application, you can use the POSIX clock_gettime() call with CLOCK_THREAD_CPUTIME_ID to measure the amount of CPU time used by a given thread. (The Dalvik VM uses this when generating results for traceview.)
This is all per-thread, however. Getting per-core usage information is much harder, especially on Android:
The hotplug mechanism can add or remove cores during your test.
The kernel can adjust the CPU frequency of each core individually, so doing X amount of work may take different amounts of time on different cores.
Threads can migrate between cores (by default there is no core affinity).

It should include the different cores (showing Nexus 7):
$ adb shell cat /proc/cpuinfo
Processor : ARMv7 Processor rev 9 (v7l)
processor : 0
BogoMIPS : 1993.93
processor : 1
BogoMIPS : 1993.93
processor : 2
BogoMIPS : 1993.93
processor : 3
BogoMIPS : 1993.93
and stat:
$ adb shell cat /proc/stat
cpu 1623573 112801 907626 32541158 125987 68 5952 0 0 0
cpu0 804181 45734 569092 7373416 43990 49 4990 0 0 0
cpu1 332438 26759 142892 8311267 31256 9 574 0 0 0
cpu2 332889 25551 130711 8319093 30900 7 218 0 0 0
cpu3 154065 14757 64931 8537382 19841 3 170 0 0 0

You can check if a core is Online/offline by reading the file
/sys/devices/system/cpu/CPUx/online (x is the number of the core and in Samsung S3: 0,1,2,3)
if it is "0" , the core is Offline and if it is "1" the core is online. Now, you can use /proc/stat to calculate CPU Usage but for Samsung S3 it will only show the cores which are active at the time you read /proc/stat. Now, to calculate CPU Usage for all the cores, you have to force all the cores online. You can use System Tuner App available at Play store: https://play.google.com/store/apps/details?id=ccc71.pmw&hl=en for forcing all the cores online. Install the app and then put the cores online by ( CPU -> Boot settings -> Force all CPUs online -> On boot Completed ), now you can reboot your device and all the cores are online. Now read /proc/stat and calculate CPU Usage for all the cores. If you need more explanation about /proc/stat http://www.linuxhowtos.org/System/procstat.htm
can help.
I noticed that load gets distributed among all the active cores (must be some system processes), I was running Skype over Wifi and without forcing all the cores online it was using 2 cores: core 0 and core 1 at 30% and 25% respectively. I measured the CPU Usage again for the same use case(Skype over wifi) after forcing all the cores online and I noticed that load was distributed among all active cores ( Core1: 26% , Core 2: 9%, Core 3: 11%, Core 4: 10% ).

Finding the names of the running activities

Edited to change 'running to 'running or paused and in background'
Is there a method which which I can log the names of the classes of the activities running or paused and in the background (i.e. not finished) in my application?
I find the shell command adb shell dumpsys meminfo com.mypackage.myapp to be most useful in managing the activity stack but it only gives me the number of activities running, not their names.
For example on startup it gives me this snippet:
** MEMINFO in pid 215 [com.mypackage.myapp] **
native dalvik other total
size: 4336 3203 N/A 7539
allocated: 4326 2527 N/A 6853
free: 9 676 N/A 685
(Pss): 1034 1974 1994 5002
(shared dirty): 2160 4732 1564 8456
(priv dirty): 864 684 912 2460
Objects
Views: 22 ViewRoots: 2
AppContexts: 3 Activities: 2
Assets: 2 AssetManagers: 2
Local Binders: 7 Proxy Binders: 11
Death Recipients: 0
OpenSSL Sockets: 0
Now I reckon I should only have one activity occupying memory, yet it tells me there are two. I'd quite like to know what the other one is.

As soon as an activity has lost focus and another activity runs the first one is paused or stopped. The conclusion is that there is always just one activity really running and that is the visible activity on the foreground.

Memory Leak in Android Phone

I have seen some memory leak in my phone.
Steps :
Open Browser (Home Page : www.google.com). It will fetch the Page.
Select Back Key to come out from browser (close).
Repeat the same steps (1-2) for 5 times.
Observer following data by "adb shell dumpsys meminfo PID (of browser) :
First Time (when open browser first time - After Step 1):
Applications Memory Usage (kB):
Uptime: 428816 Realtime: 434932
** MEMINFO in pid 899 [com.android.browser] **
native dalvik other total
size: 24296 6727 N/A 31023
allocated: 24241 3955 N/A 28196
free: 54 2772 N/A 2826
(Pss): 3455 2259 30025 35739
(shared dirty): 2064 1772 7444 11280
(priv dirty): 3388 548 21116 25052
Objects
Views: 0 ViewRoots: 0
AppContexts: 0 Activities: 0
Assets: 3 AssetManagers: 3
Local Binders: 34 Proxy Binders: 28
Death Recipients: 1
OpenSSL Sockets: 0
Second Time (After Step - 4) Opening - Closing of Browser 5 times :
Applications Memory Usage (kB):
Uptime: 473642 Realtime: 479758
** MEMINFO in pid 899 [com.android.browser] **
native dalvik other total
size: 45616 7559 N/A 53175
allocated: 45322 4850 N/A 50172
free: 29 2709 N/A 2738
(Pss): 4602 2301 51988 58891
(shared dirty): 2060 1736 7440 11236
(priv dirty): 4536 584 42360 47480
Objects
Views: 0 ViewRoots: 0
AppContexts: 0 Activities: 0
Assets: 3 AssetManagers: 3
Local Binders: 113 Proxy Binders: 47
Death Recipients: 1
OpenSSL Sockets: 0
Could you please help us to find out what data here shows which information (like what is Size, Allocated, free, Local Binders etc) and where in above data it is showing that there is memory leak.
New to all these analysis so asking basic questions :-(
Please help me for this.
Thanks
Rke

You know, I don't really see a memory leak here. The most common way to get memory leak is to have references to Activity which had to be destroyed. Anyway, there is a way to search for leak, there is a good article in Android developers blog about memory analysis in Eclipse with MAT and there is also a video from Google IO-2011. Try it, and maybe you'll find what's wrong.