Develop Reference

Why Android system tries to serialize a View?

I have a custom View and sometimes I get reported crashes for:
Caused by: java.io.NotSerializableException: com.myapp.views.MyCustomView
For few FragmentsI have declared a member of this view for easier usage not having to use findViewById all the time. I've also tried to declare member views as transient to prevent this behavior.
Very to hard to post some code, because I have no idea why this is happening, but the basic architecture is following:
Fragment with xml layout
Create MyCustomView which is FrameLayout dynamically and add to that Fragment
Initiate MyCustomView pointer and pass to another View as member for usage
Also I've never got this crash myself, I get the crash report using BugSense crash library.
UPDATE: Somehow this is connected to my one data class which implements Serializable. I decompiled the package and the crash trace also shows is actually a data class:
java.lang.RuntimeException: Parcelable encountered IOException writing serializable object (name = com.myapp.f.y)
And MyCustomViewhas a member of that object. So the Serializable object is being serialized and somehow MyCustomView tries to serialize itself too ?
UPDATE:
Crash count for avg 2k daily users is about 10 per day. Trace showing that when home pressed:
android.app.ActivityThread.handlePauseActivity(ActivityThread.java:2302)
system tries to serialize, could there be some threading issue that some operation or animation is still ongoing and thats causing system trying to serialize a View ?
UPDATE:
This seems to happen only with 2.x platform devices.

DDMS Heap - 1-byte array(byte[], boolean[])

I experience some memory leaks in my android application. I've already used MAT to analyze the memory usage. But I have one question from the DDMS perspectiv in Eclipse, what does 1-byte array[byte[], boolean[]) mean?
Is this specific for my application? You can see that this is the big memory leak issue, this always increases in size, and the rest will increase and decrease randomly. My guess is that the GC doesn't catch this type. Can anybody explain why this happen, with this little information?

One byte array is the designation for any data structure that is organized as a single byte array. In you case and with that size, I would bet in a Bitmap or a Drawble.
Most common reasons for memory leaks are static object not properly managed and holding references to:
Context
View (which holds reference to context (and possibly also to bitmap)
Thread (which are not easly collected by GC)
Handler (which holds reference to context)
Most of them can be solved ensuring that you set the object to null when it's no long required.
Regards.

A byte and a boolean are each 1 byte. If you have an array of those you have a "1-byte array".
A ByteBuffer for example should internally hold one of those.
You have a total of 614 of them where the smallest one be a byte[24] (or boolean[24]), the largest one is 3MB. All of them together use 104MB.
The GC will get rid of them if they are no longer referenced.
For example when you put
private static byte myArray[] = new byte[3 * 1024 * 1024];
in one of your classes and never set it back to null (myArray = null) then this one can't be garbage collected because another Object has a reference to it. The object would be the class itself (as in String.class). The class object can't be garbage collected since classes are never unloaded. (they are referenced by their ClassLoader which could itself be referenced / loaded by another ClassLoader and you can't create Objects & use classes without them - they need to stay and they need to keep a reference to their classes)
It's usually not that simple but often start with static somewhere.
Within MAT (after you force GC) look at the reference chain for the objects that are no longer intended to stay alive and identify the one Object that holds the reference. Set that one to null in your code and your leak is gone. Explained in more detail here:
http://android-developers.blogspot.de/2011/03/memory-analysis-for-android.html

I ran to this problem tonight and almost I checked every bit of code but I couldn't find anything.
What I did was starting the app from intelij and then pressing home button and open the app again. Every time the app heap was doubled.
Finally I discover when I launch the app from ADB and press the home button and open the app again it doesn't bring back the old activity, it just start a new one. When I pressed finish it starts to cycle through all of them. It's like they are treated as two different intent. So I put android:launchMode="singleTop" on the main activity in manifest and it resolved the problem.
Although it's not the main cause of this problem but if you encountered this check this out before anything. It wasted three or four hours for me.

R.id. values get overwritten

In my Android app I'm creating new WebViews from Java code; however after I create these WebViews my previously working id's get overwritten.
Example snippet:
for (int i=0;i<mywebviewarray.length;i++){
mywebviewarray[i]=new WebView();
}
((Button)findViewById(R.id.mybutton).settext("ok");
If I run this code, I get an exception on the last line:
java.lang.ClassCastException: android.webkit.WebView
It seems to me as if the tables backing the findViewById get overwritten. I tried calling setId in the loop. but it does not help.
How can I resolve this problem?

What is in mywebviewarray. It seems to me like you have something in there that isnt a WebView and you are trying to instantiate it as a WebView.

I ended up not solving this problem, and instead of using a dynamic array of WebViews, I ended up using fixed 3 WebViews. I'm changing their content like a 3-length window over an array of URLs, thus simulating the original concept. (Albeit in a slower way)

Strange exception in application

I have recently put an application on the Market and I have received until now 7 errors that look like the following:
java.lang.IllegalArgumentException: Wrong state class, expecting View State but received class android.widget.ProgressBar$SavedState instead. This usually happens when two views of different type have the same id in the same hierarchy. This view's id is id/0x2. Make sure other views do not use the same id.
Can someone tell me how to debug the problem? What is View with id 0x2 - is there a way to find out?

I've received this error under the following conditions - I'm replacing the icon of an item in the actionbar (in my case a throbber for a refresh button), and while it's in that state, I rotate the device. This error arises from it trying to restore the view's saved state and noticing the difference between what's declared and what's serialized.

There should be a stacktrace next to the report which could help you find the exact line of code.

android Low memory:no more background process ?? Need help

I am facing the problem of low memory. Low memory:no more background process And here is the scenario.
I am using a list which gets its data from a string array, it has a custom background, Clicking on item, the list gets another string array to display as second or third level. Information for three levels written in database.
After third level, there are two more levels for which data is going to be fetched from web services,
And that causes the low memory error.
How can I get rid of the solution?
Edit : After having some digging I found that the GC is trying to (kill or) restart in case of its already crashed com.android.inputmethod.latin/.latinIMEservice. One notable point is that the application is translated in french and italian, but this screen does not have any text for translation, does this information helps??
Edit 2: After a detailed study of traceview I found that all the text views have custom fonts applied in it. (There is a call of TypeFace.createFromAsset()) that IMO causes the crashes.
And the problem lies in the fact that I have to keep the fonts....
can It be possible to avoid crash and have the fonts?? (Because i think the answer is no: But still waiting for some opinions)
Edit 3 : After removing the custom fonts the performance of application is much better. Hence I can suspect the font is the only culprit here. And that's why I am editing question. The font I use is helvetica.
Can using external fonts cause application to crash or running out of memory? If yes can you describe the cause in more detail??
Thanks

If you are using code similar to:
Typeface font = Typeface.createFromAsset(getContext().getAssets(),
"fonts/Helvetica.ttf");
try making "font" a global variable so it only gets loaded once. Otherwise it can be loaded repeatedly, quickly consuming memory. See this message for a little more detail

Well, question is a bit unclear to have answered:
After each level - do you switch/start to another Activity? If so you shouldn't keep anywhere references to old activity. Otherwise it could trigger OOM problems
I suppose you're fetching data using some kind of Cursor alike object. Cursor's are very memory-consuming objects, so you'd better not only just close Cursor's, but you should also call Cursor.deactivate()