android - TextView with id and textIsSelectable="true" causes leaking of the Activity object -

it took me 3 days narrow problem memory leak , can't find else describing issue anywhere. that's why ask if confirm haven't missed something. i've submitted bug report reason i'm asking here on (besides letting others know) let me know of other views , attributes causing such problems can avoid them.

my problem follows:

(1.) create simple android application (e.g. skeletonapp sample application)

(2.) add following @ end of oncreate() cause memory allocation:

log.i(this.tostring(), ">>> oncreate()"); auxlist = new arraylist<int[]>(); for(int = 0; < 20; i++) {   auxlist.add(new int[250000]); } log.i(this.tostring(), "<<< oncreate()"); 

(3.) (optional - convenience) override following methods:

@override protected void ondestroy() {   log.i(this.tostring(), ">>> ondestroy()");   super.ondestroy(); }  @override protected void finalize() throws throwable {   log.i(this.tostring(), ">>> finalize() !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");   super.finalize(); } 

(4.) run application , rotate screen several times (pressing left ctrl+f11) - should work now

(5.) in layout (skeleton_activity.xml) add:

<textview   android:id="@+id/textviewdebug"   android:layout_width="30dp"   android:layout_height="32dp"   android:textisselectable="true" /> 

(6.) repeat point (4.) - logcat reveals activity destroyed after rotation never finalized causing outofmemory error after several rotations

(7.) removing textisselectable attribute or setting false removing id attribute (even while keeping textisselectable="true") prevents issue.

thanks comments!

ps: i'm new here , have no rights add new tags. enough points add "textisselectable" tag question? thanks

check android docs use cases finalize. finalize expensive, , causing memory leak, not value on text field.

android object

note objects override finalize more expensive objects don't. finalizers may run long time after object no longer reachable, depending on memory pressure, it's bad idea rely on them cleanup. note finalizers run on single vm-wide finalizer thread, doing blocking work in finalizer bad idea. finalizer necessary class has native peer , needs call native method destroy peer. then, it's better provide explicit close method (and implement closeable), , insist callers manually dispose of instances. works files, less biginteger typical calling code have deal lots of temporaries. unfortunately, code creates lots of temporaries worst kind of code point of view of single finalizer thread.