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>

Troubleshooting android app memory usage problems

I would like to know how I can troubleshoot high memory usage problems of my app on Android. I've search the internet and found out that the DDMS plugin is useful in taking a memory dump of the heap for my app. This however has been useless.
The app "Usage Timelines Free" is showing 94 MBs of memory used, while the DDMS heap dump shows me a total of 8.4 MBs, with the suspected leaks being the resource files.
When I generate a dump from adb (dumpsys meminfo), I get:
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 20 8 20 54588 39431 1892
Dalvik 6732 9952 6396 10756 10028 728
Cursor 0 0 0
Ashmem 184 0 184
Other dev 11462 1172 11384
.so mmap 2467 2072 1156
.jar mmap 0 0 0
.apk mmap 48 0 0
.ttf mmap 2 0 0
.dex mmap 1037 0 0
Other mmap 41 16 32
Unknown 46352 292 46348
TOTAL 68345 13512 65520 65344 49459 2620
How can I know what is behind this huge memory consumption. My app is a foreground monitor service which runs forever, with a few activities which are accessed a few times per day.
Thanks.

Minimize your android data usage. Check the link :http://engineroots.games4punk.com/minimize-your-android-data-usage/

DDMS and got a heap memory dump. It only showed 8.4 MBs being used!
Then you are only using 8.4MB of heap space after a complete garbage collection (a net effect of creating the heap dump).
Note that if you ran this on Android 1.x/2.x, MAT will not report space consumed by bitmaps. Always try to dump the heap from an Android 3.0+ device or emulator.
When I generate a dump from adb (dumpsys meminfo), I get:
My guess is that you are running this on an Android 1.x/2.x device or emulator, and you have a lot of bitmap memory. Try running your heap dump and other tests on an Android 3.0+ environment.
Also, bear in mind that adb dumpsys meminfo does not perform a complete garbage collection, whereas dumping the HPROF file does. The Android garbage collector is optimized to minimize CPU utilization and therefore does not attempt to perform a complete garbage collection. Hence, at runtime, the heap is usually filled with garbage that will be reclaimed, as needed, by the GC engine.
You might also wish to read Dianne Hackborn's essay on this subject.

Android`s native size

I saw great article below,
How do I discover memory usage of my application in Android?
but, I have a question in that article,
** MEMINFO in pid 890 [system] **
native dalvik other total
size: 10940 7047 N/A 17987
allocated: 8943 5516 N/A 14459
free: 336 1531 N/A 1867
(Pss): 4585 9282 11916 25783
(shared dirty): 2184 3596 916 6696
(priv dirty): 4504 5956 7456 17916
Heap size make sense, however native size is ridiculous.
Why not NativeFree = NativeSize - NativeAllocated ?
I uploaded question like this, but answer doesn`t help me. I ask again.

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.