Develop Reference

Android ViewPager2 library throwing Transactiontoolarge exception onpause event

I am getting TransactionTooLarge exception if page size = 50 and I press the home button. I checked the FragmentStateAdapter and found that 'saveState()' method is finalized.
Please help me how to resolve this.
In ViewPager it was overriden by me using below link-
https://medium.com/#mdmasudparvez/android-os-transactiontoolargeexception-on-nougat-solved-3b6e30597345
But no way in View pager2 library.

I had terrible random crash with my fragments.
The one megabyte limit is system wide, so it can crash at much lower thresholds.
I fixed the issue by stopping to use serialized objects and only passing integers into intents and fragment arguments.
Then fragments and activities can get the actual object from a repository using the integer id I gave to it.
It is faster and with insight it is a lot simpler.

InputConnectionWrapper is not finalized and is causing a memory leak in Android

In certain situations, I create an EditText, pass the value to another Fragment, and then call removeAllViews on the ViewGroup that the EditText belongs to remove EditText.
The problem is that the InputConnectionWrapper associated with the EditText is still occupying memory.
In the above Heap Dump, the InputConnectionWrapper is allocated over 300 and takes up considerable memory.
However, with the Heap Dump enabled, there is only one EditText in the Activity, and it is judged that the InputConnectionWrapper is not created due to the corresponding EditText.
To close the InputConnectionWrapper, I tried the following function.
TextKeyListener.clear(editText.getText());
editText.setHint(null);
editText.removeTextChangedListener(this);
editText=null;
// The ViewGroup will then execute removeAllViews.
However, the InputConnectionWrapper seems to be allocated more over time as it is not finalized.
What is the reason InputConnectionWrapper will not be finalized?

I ran into the same issue found via LeakCanary giving me a chain of InputConnectionWrapper'd wrapping an EditText.
It looks like this is a bug in Android code that was fixed in Marshmallow. When I upgraded my min API version from 21 (Lollipop) to 23 (Marshmallow), the problem went away.

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

it took me three days to narrow my problem with this memory leak and I can't find anyone else describing this issue anywhere. That's why I would like to ask if someone could confirm I haven't just missed something. I've also submitted a bug report but the reason I'm asking here on SO (besides letting others know) is that I would like you to let me know of other Views and their attributes causing such problems so I can avoid them.
My problem is as follows:
(1.) create a simple Android application (e.g. the SkeletonApp sample application)
(2.) add the following at the end of onCreate() to cause memory allocation:
Log.i(this.toString(), ">>> onCreate()");
auxList = new ArrayList<int[]>();
for(int i = 0; i < 20; i++) {
auxList.add(new int[250000]);
}
Log.i(this.toString(), "<<< onCreate()");
(3.) (optional - just for convenience) override the 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 the application and rotate the screen several times (pressing left CTRL+F11) - everything should work for now
(5.) in the 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.) - the logCat reveals that the Activity is destroyed after rotation but never finalized causing OutOfMemory error after several rotations
(7.) removing the textIsSelectable attribute or setting it to false as well as removing the id attribute (even while keeping textIsSelectable="true") prevents the issue.
Thanks for you comments!
PS: I'm new here and have no rights to add new tags. Could someone with enough points add a "textisselectable" tag to this question? Thanks

Check the Android Docs for use cases with finalize. Finalize is expensive, and is probably what is causing your memory leak, not the value on your text field.
Android Object
Note that objects that override finalize are significantly more expensive than objects that don't. Finalizers may be run a long time after the object is no longer reachable, depending on memory pressure, so it's a bad idea to rely on them for cleanup. Note also that finalizers are run on a single VM-wide finalizer thread, so doing blocking work in a finalizer is a bad idea. A finalizer is usually only necessary for a class that has a native peer and needs to call a native method to destroy that peer. Even then, it's better to provide an explicit close method (and implement Closeable), and insist that callers manually dispose of instances. This works well for something like files, but less well for something like a BigInteger where typical calling code would have to deal with lots of temporaries. Unfortunately, code that creates lots of temporaries is the worst kind of code from the point of view of the single finalizer thread.

Ok, I got an answer to my bug report stating that it can't be reproduced with the newest version of Android (I tested it on two devices running ICS). So I guess I'll just have to believe them as I don't have any newer device and it doesn't seem to bother anyone anyway. It's just a memory leak after all... ;-)

Does multithreading affect programs in OpenGL ES for android?

I have got some strange and unexpected results from my program in OpenGL ES for android for example in the code below:
matrix = ThisRot.get();
gl.glMultMatrixf(matrix, 0);
currentRotation.toMatrix(matrix);
temp.set(matrix);
I set the matrix value before I use it as an argument for gl.glMultMatrixf and after that I change the value of matrix and use it for another purpose, but it has effect an the way the object rotate so it should have effect on gl.glMultMatrixf(). and that's not the only one, some other places in my code I had this unexpected results. so I have thought maybe these happen due to mutual exclusion and multitreading and those kind of things.
am I right? should we worry about multithreading when we code in Opengl ES for android? How can I avoid these kind of problems.

Of course you should worry about multithreading. In particular, Android creates its own GLThread for rendering, when you attach a GLRenderer-derived class to a GLSurfaceView using the setRenderer() function.
In fact, multithreading can cause crashes (not only unexpected behavior) in your programs especially when you loop through arrays adding/removing objects and such.
Check if you are modifying the same data inside the onDrawFrame function of your GLRenderer and your own thread. If you are, try adding the following around the modified code (in both threads):
synchronize(variable) {
modify(variable);
}
This will lock the variable throughout the modify() function until it ends the block. Try not to overuse it, though, only in places where you need it. One thread will block the other one until it's finished!

unexpected android system call makes smooth display of scrolling graphic stutter

I am currently writing an app that should display a real time measurement curve in a scrolling fashion (think ECG recorder or oscilloscope). An unexpected system call in the UI-Thread makes the display stutter.
The data rolls in via bluetooth. All works fine and the display is reasonably smoothly scrolling with an average update rate of 26 frames/s. But, nevertheless the display is stuttering remarkably.
I used traceview to get more insight and according to traceview the stuttering is the result of a call to android/view/ViewRoot.handleMessage which lasts 131 ms per call on average.
If I dig down further in traceview the cycles are burnt inside android/view/ViewRoot.performTraversals. 92% of these CPU cycles are consumed in mostly recursive calls to android/view/View.measure.
From there it gets complicated due to the recursive call structure. But I can find calls to the onMeasure() method of LinearLayout, FrameLayout and RelativeLayout. The onMeasure() method of each Layout type consumes about the same amount of CPU cycles. Which is very strange since in my activity I use only a simple LinearLayout with just 2 Elements.
I just see no reason on why a supposed re-layout of a LinearLayout with 2 Elements performs calls to non-used Layouts and takes a whopping 131 ms to do that.
Further info:
Platform HTC desire HD with Android 2.3.1.
I use a handler to perform the drawing in the UI thread.
The Layout is a simple LinearLayout with 2 Elements: a custom view and a textField.
The status bar is hidden with getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);.
The drawing is performed on each new block of data, which arrives approx. every 50 ms.
The drawing itself uses a canvas and is performant enough to keep up with the incoming data.
After that long explanation, here are the questions:
What is calling the android/view/ViewRoot.handleMessage? (the calls are relatively equal spaced every 850 ms and have no obvious link (no direct calls, number of calls and relative positions are not linked to the message handler for drawing) to any activity of my Activity)
How can I suppress the calls to android/view/ViewRoot.handleMessage or how can I make them faster (there are just 2 elements in my LinearLayout)
the calls to unused layouts first got me think of the status bar or some hidden activity (e.g. home screen), which may use such layouts. But how come those calls are part of the trace of my activity? As far as I understand the trace should only trace the active process. e.g. the calls of my service which produces the real time data is not part of the trace.
Is there any possibility to trace individual calls to some system components? When I zoom in in traceview I see this call sequence: toplevel -> android/os/Message.clearForRecycle() -> android/os/MessageQueue.nativePollOnce() -> android/os/SystemClock.uptimeMillis() -> com/htc/profileflag/ProfileConfig.getProfilePerformance() -> android/os/Handler.dispatchMessage() -> android/view/ViewRoot.performTraversals()
Off topic: Is there a possibility to export the data which is shown inside traceview (parents-children-CPU time etc.) other than a screenshot?

Ok, I found the reason for the long call to android/view/ViewRoot.handleMessage.
This was indeed caused by my application.
My App has 2 screens (Activities) one with a complicated Layout for status information and the other one the real time display of incoming data.
The data, which comes in over bluetooth contains mixed real time data and status data. When I switch to the real time Activity, I was stopping the status Activity with finish(); after starting the new real time Activity. Unfortunately this is not enough to stop also the message handler, which receives the new status information in the UI thread, and continued to update status data in an invisible and finished Activity. The relayout of this activity caused the stutter of the real time data.
This is now solved. The display scrolling is now reasonable smooth.
Thanks for your patience. May it be useful to anyone who stumbles on this Thread on stackoverflow.
jepo