Develop Reference

how to solve W/art : Could not create image space with image file '/system/framework/boot.art' while trying to port Android Lollipop on Arndale Board?

Iam trying to port Android Lollipop on arndale board and I am facing following issue regarding ART crash (AndroidRunTime).
> I/art ( 2264): RelocateImage: /system/bin/patchoat
> --input-image-location=/system/framework/boot.art --output-image-file=/data/dalvik-cach6 F/libc ( 2443): No [stack] line found in "/proc/self/task/2443/maps"! F/libc ( 2443): Fatal signal 6
> (SIGABRT), code -6 in tid 2443 (patchoat) W/art ( 2702): Could not
> create image space with image file >/system/framework/boot.art.
> Attempting to fall back to imageless running
STEPS FOLLOWED FOR PORTING
1.Download vexpress android L 32 bit code from below link.
http://releases.linaro.org/15.05/android
2.Download arndale android KK 32 bit source with 3.9 kernel from http://releases.linaro.org/14.08/android/arndale
3.Replace the Vexpress kernel source from code download in step 1 with arndale KK 3.9 Kernel source downloaded from step2.
4.Replace Vexpress HAL (device/linaro/vexpress) with Arndale HAL (device/linaro/arndale).
5.Solve minor complilation issues related to bionic and build environment.
After flashing the images and powering on the board I am stuck at android logo and kernel crashes
> >37.790000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 Tainted: G W (3.9.1 #8) [ 37.790000]
> CPU: 0 Tainted: G W (3.9.1 #8) PC is at
> __copy_to_user_std+0x4c/0x3a8 [ 37.790000] PC is at __copy_to_user_std+0x4c/0x3a8 LR is at 0x6c000000
> >[ 37.790000] LR is at 0x6c000000
and logcat gives
> >I/art ( 2264): RelocateImage: /system/bin/patchoat --input-image-location=/system/framework/boot.art --output-image-file=/data/dalvik-cach6 F/libc ( 2443): No [stack] line found in "/proc/self/task/2443/maps"! F/libc ( 2443): Fatal signal 6
> (SIGABRT), code -6 in tid 2443 (patchoat) W/art ( 2702): Could not
> create image space with image file >/system/framework/boot.art.
> Attempting to fall back to imageless running.
POINT OF EXACT FAILURE
1.ART calls Thread::InitStackHwm from art/runtime/thread.cc.
2.The above call triggers __pthread_attr_getstack_main_thread(stack_base, stack_size) in bionic/libc/bionic/pthread_attr.cpp which returns No [stack] line found in enter code here/proc/self/task/2443/maps! and ART crashes giving SIG_ABORT and it seems as if no stack is getting created for 2443 thread, but how to solve this?
It would be great if anyone can help me to solve this issue.
Thanks,
Devarsh

This is a side effect of using 3.9 kernel with linaro vexpress android platform which is expecting 3.10 kernel(whose support for arndale is not available).
As a workaround comment out the InitStackHwm() function in art/runtime/thread.cc.
I think if in 3.10 kernel support of arndale is needed we may not need this workaround and ART would work straightaway.
void Thread::Init(ThreadList* thread_list, JavaVMExt* java_vm) {
// This function does all the initialization that must be run by the native thread it applies to.
// (When we create a new thread from managed code, we allocate the Thread* in Thread::Create so
// we can handshake with the corresponding native thread when it's ready.) Check this native
// thread hasn't been through here already...
CHECK(Thread::Current() == nullptr);
SetUpAlternateSignalStack();
InitCpu();
InitTlsEntryPoints();
RemoveSuspendTrigger();
InitCardTable();
InitTid();
// Set pthread_self_ ahead of pthread_setspecific, that makes Thread::Current function, this
// avoids pthread_self_ ever being invalid when discovered from Thread::Current().
tlsPtr_.pthread_self = pthread_self();
CHECK(is_started_);
CHECK_PTHREAD_CALL(pthread_setspecific, (Thread::pthread_key_self_, this), "attach self");
DCHECK_EQ(Thread::Current(), this);
tls32_.thin_lock_thread_id = thread_list->AllocThreadId(this);
//InitStackHwm(); This is the workaround
tlsPtr_.jni_env = new JNIEnvExt(this, java_vm);
thread_list->Register(this);
}

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: do I have a memory leak?

I am working on an lwp where over time, the memory usage reported thru the UI (settings, apps, running) shows an ever increasing memory usage (starts at ~18M and has climbed as high as 90M before I nuked it). That seems very bad and got me hunting down what must be a memory leak. So I used ddms and it shows that while the the app shows increasing memory usage, the Dalvik allocated heap is ~13.7M and it doesn't vary more than ~500K over time. OK, so it must be on the native heap. I included a log of Debug.getNativeHeapSize() and Debug.getNativeHeapAllocatedSize() and they both report ~5M of native heap +/- ~2M, consistently as the UI shows the increasing memory usage. What other memory usage is there besides Dalvik and native? So I read Diane Hackborn's excellent post here and realized I had a lot more to learn. I used adb shell dumpsys meminfo and the result looked like:
** MEMINFO in pid 6856 **
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 1118 1116 1076 5072 3452 59
Dalvik 4102 16204 3584 15111 14077 1034
Cursor 0 0 0
Ashmem 2 4 0
Other dev 33344 292 820
The huge 33M "Pss" for "Other Dev" plus the Native/Pss and Dalvik/Pss is roughly what the UI is reporting for memory usage. Reading Diane's post, I don't know if I should be worried about my memory usage or not. I can see that that "Pss/Other dev" value is climbing over time but my native and Dalvik heap are remaining where ddms and the Debug.getNativeHeapSize() report they are. I'm confused and don't know if I should be concerned other than that users will see that my lwp is consuming this crazy amount of "memory" when as far as I can see, it is not actually leaking.
Does anyone understand what is going on here? This on a Galaxy Nexus, ICS 4.0.2.
EDIT: I subsequently tried to crash the app by letting the Other/Pss climb until the app reached ~200M of reported usage in the UI. It did crash:
E/IMGSRV ( 8337): :0: __map: Map device memory failed
W/GraphicBufferMapper( 8337): registerBuffer(0x3364c0) failed -14 (Bad address)
F/libc ( 8337): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
I/DEBUG ( 114): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
So I have something to fix, I have no idea where to start since I can't see any problem on the dalvik or native heap.

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.

App using NDK (native code) falls. How can i find out why?

My app is using NDK (4r-crystax in my case) to proccess images from a camera. Problem is, it falls after few minutes of work. I guess there can be some memory leaks or something like that, but i dont know how to find out where the problem is. This is a log around this error:
04-14 23:07:37.133: INFO/NATIVE CODE(14895): Detection percentage counted.
04-14 23:07:37.163: DEBUG/MDDetectorView(14895): Some debug info
04-14 23:07:37.193: DEBUG/dalvikvm(14895): GC_EXTERNAL_ALLOC freed 19 objects / 872 bytes in 27ms
04-14 23:07:37.283: INFO/NATIVE CODE(14895): Image to proccess loaded.
04-14 23:07:37.493: INFO/ActivityManager(92): Process com.motiondetector (pid 14895) has died.
04-14 23:07:37.493: DEBUG/CameraService(67): Client::~Client E (pid 67, client 0xad08)
04-14 23:07:37.503: INFO/WindowManager(92): WIN DEATH: Window{46590698 com.motiondetector/com.motiondetector.MDMenuActivity paused=false}
04-14 23:07:37.513: ERROR/CameraService(67): getClientFromCookie: client appears to have died
Any ideas? Are there any usefull tools to help me find answer?
Is possible that Android kill on screen activity during proccessing a native code?

If you're using NDK r5 or greater, you can use the ndk-gdb script to run your program and connect to it via GDB. If your native code is crashing, it should drop you into the GDB command line, where you can examine the area of code that's causing the problem.