Is the Android activity instanceState cleaned during app upgrade?

Question

In the instanceState of an activity we store a Serializable (bundle.putSerializable). In a crash report from the Play Store we saw the following stack trace:

Caused by: java.lang.ClassNotFoundException: o.ণ
at java.lang.Class.classForName(Class.java)
at java.lang.Class.forName(Class.java:308)
at android.os.Parcel$2.resolveClass(Parcel.java:2373)
at java.io.ObjectInputStream.readNewClassDesc(ObjectInputStream.java:1641)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:657)
at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1782)
at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:761)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:1983)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:1940)
at android.os.Parcel.readSerializable(Parcel.java:2381)

Our code is obfuscated by DexGuard. It looks like Android is able to serialize the class but not able to deserialize the class.

The only reason we currently can think of is an upgrade of the app (via de Play Store). Between the version the class is changed (because of Dexguard) making a deserialization impossible.

So, my question is: does Android clean all instanceState of an app during the upgrade of an App or not?

Does your app handle any special kind of `Intent`s, e.g. by calling or providing an internal `Service`? — JimmyB, Sep 14 '15 at 15:05
Yes, we have an internal service started with an Intent with bundle parameters. However the problem I describe above is a problem from within an Activity. — userM1433372, Sep 15 '15 at 07:16
Mimmo, that is also my expectation but i'm not sure. Where did you find the information? — userM1433372, Sep 22 '15 at 13:27
In theory the id of views con chance at every build. This is another evidence that when you install a new version of an app the state cannot be considered valid. — Mimmo Grottoli, Sep 22 '15 at 18:38

score 1 · Answer 1 · answered Sep 18 '15 at 09:15

As far as I know, the only condition under which the system restores the state of an Activity when it's completely destroyed is when the system had to destroy that Activity to recover system memory. In all other cases (force process to stop, reinstallation of the app, restart of the device) the state is lost.

About the reinstallation, you have to consider that when you install a new version of the app, you have probably changed or removed one or more activities, and the state of the old activities cannot probably match the state of the new ones. Suppose for example that in a single Activity app, you have a TextView with id "@+id/my_text". After few days, you decide to remove the TextView and assign the id "my_text" to another View - for example a Spinner: how could the system restore the text of the TextView in a Spinner?

score 1 · Accepted Answer · answered Sep 23 '15 at 11:46

1

You shouldn't include custom classes in the saved instanceState if there is any chance that those classes will change (even if it's only DexGuard shuffling names around). The system persists some information about recent activities and may try to reuse it across upgrades.

answered Sep 23 '15 at 11:46

wojtek.kalicinski

1,090
7
13

Is this your experience or did you find this in the documentation? – userM1433372 Sep 23 '15 at 11:47
So you should never use putSerializable() in an intent parameter bundle with your own classes? – userM1433372 Sep 23 '15 at 12:22
"if there is any chance that those classes will change". Consider it like an external API of your app, if you change it - things might break. I found it in internal resources, I don't think public documentation specifically calls out this situation. – wojtek.kalicinski Sep 23 '15 at 12:33
To me this answer is wrong. The state must be lost after an upgrade of an app. – Mimmo Grottoli Sep 23 '15 at 15:25

Is the Android activity instanceState cleaned during app upgrade?

2 Answers2