I want to acquirećAndroid Device VRAM size.
Is there a method for acquisition from the program?
Let's do some calculation using Nexus One:
Screen resolution is 480x800. So minimum required video memory size would be:
400 * 800 * 4 bytes = 1536000 bytes
Assuming that driver may (and normally should) use several buffers, we should also expect values like:
1536000 * 2 bytes = 3072000 bytes
1536000 * 3 bytes = 4608000 bytes
etc...
It would be weird to have values that are not multiple of 1536000 (or W x H x 4 in general).
After some searches on Android internals I've found this documentation :
...Android makes two requirements of the driver: a linear address space of mappable memory that it can write to directly...accessing the driver by calling open on /dev/fb0...
So I tried and take size of /dev/graphics/fb0 file (on my device there is no /dev/fb0).
But a direct approach doesn't work:
File file = new File("/dev/graphics/fb0");
file.length(); // ==0, doesn't work, no read access
Using next trick you can get actual size of fb0:
>adb pull /dev/graphics/fb0
1659 KB/s (4608000 bytes in 2.712s)
Video memory is ~4mb (Nexus One). Let's check if this is multiple of Nexus screen size:
4608000/1536000 = 3
It looks like a right value. And we also can say that driver uses three screen buffers.
So, as a conclusion, you can detect video memory size using adb, but you can't use this approach from your android application in runtime due to file access restrictions.
You typically do not have a dedicated "VRAM" on mobile devices. At least you don't have it with PowerVR architectures (wich totally dominate the market with their MBX and SGX cores).
That is, the OpenGL driver allocates normal RAM until you run out of it, and the more you allocate the less you have left for your application.
The Android/OpenGL APIs don't offer explicit methods to read the VRAM size from a given device.
Poor man solution:
You could try to infer the VRAM size in an empiric way adding 1MB texture until you get an out of memory error from gl.glGetError().
From your "dmesg" output u can read off the VRAM, so for my Tablet:
> [ 0.000000] Machine: TDM3730 [ 0.000000] Reserving 12582912
> bytes SDRAM for VRAM
>
> 7>[ 3.929962] VRAM: checking region 9f400000 3072
> <4>[ 3.929992] Failed. Allocating 4194304 bytes for fb 0
> <7>[ 3.935333] VRAM: alloc mem type 0 size 4194304 paddr dec2bd4c
> <7>[ 3.935485] VRAM: checking region 9f400000 3072
> <7>[ 3.935485] VRAM: found 9f400000, end a0000000
> <6>[ 3.936584] android_usb gadget: high speed config #1: android
> <4>[ 3.960113] allocating 4194304 bytes for fb 1
or details at:
http://pastebin.com/jQSXQqHh
Is simple just count how many Mb ram that from usable to real capacity of the ram, example for my lenovo a369i has 512 RAM Module, but in setting app only showing 471 Mb usable so the 41Mb left is reserved for the GPU, so the conclusion is my a369i has 41Mb vram
This method is based from shared graphics memory (wiki)
I suspect that android.os.StatFs is what you're looking for:
http://developer.android.com/reference/android/os/StatFs.html
Related
I am currently working on NXP's NTag213 and NTag215 and while I was going through the document, it confused me. Let me explain
For NTag213, it has 45 pages in total, each with 4 bytes so a total of 180 bytes. Out of these 180 bytes(45 pages), 36 bytes(9 pages) are used for the serial number, CC, static and dynamic lock bytes, configuration bytes, password bytes and RFU. The remaining 144 bytes are user memory.
Similarly For NTag215, it has 135 pages in total, each with 4 bytes so a total of 540 bytes. Out of these 540 bytes(135 pages), 36 bytes(9 pages) are used for the serial number, CC, static and dynamic lock bytes, configuration bytes, password bytes and RFU. The remaining 504 bytes are user memory.
Now in the document, I found the below statement
it states that byte 2 of CC defines the available memory size for NDEF messages. What does that mean?
Moreover, for NTag 213 we see NDEF memory size as 144 bytes equivalent to user memory size but with NTag215, NDEf memory size is 496 and its not eqivalent to user memory size of 504 bytes. Please explain what am I missing here? Thanks
It specifies "on delivery", from table 6 in section 8.5.6 here we can see that pages 4 + 5 are populated on delivery even though they are part of the user memory. This would equate to the 8 bytes missing.
I'm making application for watching movies which shows images of categories and movies in grid, list and horizontal scroll view.
App has several activities and in every one of them are shown images. Proglem is when user changes activities going only forward, in one point app crashes with OutOfMemory exception.
Using Heap and MAT tools i found that bitmap uses enormous memory of the heap in every activity. On same phones, like Samsung Galaxy S4 and Alcatel OneTouch Idol with full HD display, app crashes in just 2-3 activities. That is crazy :)
So, my question is, how can i overcome this problem with memory?
I know that this is ordinary Android problem but there must be something that I can do to fix this.
Every image is optimazed for its place ( image dimensions are precisely measured before attached to image view).
Cheers.
Do some profiling .
You didn't provide any code or logs .So ,will tell you basic approach which i follow .
start your first activity . Continously run adb shell dumpsys "PID" or "PackageName" .
Get info while you reproduce activity .
execute adb shell " while true ; do dumpsys meminfo 22188 ; done ; " > dumpsysOfsmthn.txt
* MEMINFO in pid 22188 [com.sec.android.smthn] **
Pss Private Private Swapped Heap Heap Heap
Total Dirty Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------
Native Heap 44 44 0 0 11132 10455 184
Dalvik Heap 19189 18804 0 0 25660 19221 6439
Dalvik Other 3891 3828 0 0
Stack 200 200 0 0
Ashmem 2 0 0 0
Other dev 8168 7844 4 0
.so mmap 1990 1032 508 0
.jar mmap 5 0 4 0
.apk mmap 315 0 124 0
.ttf mmap 21 0 4 0
.dex mmap 6553 248 5584 0
Other mmap 90 4 20 0
Unknown 5743 5740 0 0
TOTAL 46211 37744 6248 0 36792 29676 6623
Objects
Views: 39 ViewRootImpl: 1
AppContexts: 4 Activities: 1
Assets: 3 AssetManagers: 3
Local Binders: 78 Proxy Binders: 42
Death Recipients: 2
OpenSSL Sockets: 0
SQL
MEMORY_USED: 286
PAGECACHE_OVERFLOW: 53 MALLOC_SIZE: 62
DATABASES
pgsz dbsz Lookaside(b) cache Dbname
4 24 53 2/17/3 /data/data/com.sec.android.smthn/databases/sns.db
4 32 55 1/13/2 /data/data/com.sec.android.smthn/databases/picasa.db
4 36 27 10/17/3 /data/data/com.sec.android.smthn/databases/local.db
Applications Memory Usage (kB):
Uptime: 31556347 Realtime: 96096816
Check which part of portion is increasing constantly .
It could be ViewRootImpl or activity context or anything .
Above information might get you to some clue .
As told take heapdump analyse it with MAT or JHAT .
Mat is awewome tool IMHO .
you should look for memory leaks caused by:
Long-lived references to an Activity, Context, View, Drawable, and other objects that may hold a reference to the container Activity or Context.
Non-static inner classes (such as a Runnable, which can hold the Activity instance).
Caches that hold objects longer than necessary.
Leak can be caused by any Object.Generally bitmaps are big. And if the out-of memory occurs very easily then you need to check on heavy objects like bitmaps.
For MAT and Leaks understanding Click this
Also this .
Also apart from above things you can also use DDMS allocation tracker to get more clue > yeah nothing can get better data than MAT .
Also check this post . Very informative
I have an android app, this application connect to server to download images, but this images has more than one copy, first copy 1600 * 1080 pixel and the second is 800 * 540 ...
so the device should send tag to server to download the good images for this device
I used many ways to check the device memory or density but the results was not clear enough to make a decision, here some code I used:
float density = getResources().getDisplayMetrics().density;
long mem = Runtime.getRuntime().freeMemory();
long heap = Debug.getNativeHeapAllocatedSize();
the results was for 3 devices like this:
samsumg tab 10 inch = 1.0 , 745464 , 3249552 byte
china tab 7 inch = 1.0 , 559944 , 2789016 byte
htc moble 3.4 inch = 1.5 , 1760904 , 8942736 byte
as the result showed the htc is the better but it was not because I can't view the highest resolution on it, but on the other devices it was very good
the error msg:
java.lang.OutOfMemoryError: bitmap size exceeds VM budget(Heap Size=7687KB, Allocated=3356KB, Bitmap Size=25092KB)
Any help in this issue ?
Your decision should depend on two factors:
Screen density.
Screen Size.
In your case you had received hdpi drawables on htc, but it's small device, so it's not required to show large image with more details on small device.
for more information for loading large bitmaps efficiently:
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html
On my xperia ray app fails on start when memsize > 50mb (can't alloc so mush). But when memsize = 50mb, app can work around 5 mins, and then fails with message from marmalade, that not enough memory. So how can i find out how mush memory my app needs in peak?
In my .icf file:
MemSize=200000000
#if resolution < 1080x1920
{ [s3e]DispAreaQ < 2073600 }
MemSize=150000000
#if resolution < 640x854
{ [s3e]DispAreaQ < 546560 }
MemSize=52428800
{}
You need to turn on simulator's view matrix option and look under graphics's memory. Check what's the max size it's using. Although simulator's memory usage is different from device's usage, but it'll give you an idea about what memory size is required.
Edit:-
If you need to have different Memsize for debugging you can use MemSizeDebug too, along with MemSize.
i am making an application and on the start of application i want to display a picture but i get this out of memory exception. i used a lot of shared Preferences in the code that is not yet executed. so this rises 2 questions -
is memory for shared Preferences allocated at the beginning itself ?
and is the memory for shared Preferences allocated in the apps heap memory ?
should i clear the shared preferences and use database instead . will that solve the problem ?
Android hardware must at least support 2048x2048.
For OpenGL I used:
int[] maxSize = new int[1];
gl.glGetIntegerv(GL10.GL_MAX_TEXTURE_SIZE, maxSize, 0);
For Nexus 4 it equals to 4096
For Sansung 2 it equals to 4096
You can calculate [(Height in pixels) x (length in pixels) x (bit depth)] / 8 / 1024 = image size in kilobytes (KB)
So be sure that you have proper image size.
Hope it will help,