Crashed on launch after F-Droid update to 7.0 #55
Comments
|
Ok, I just investigated and I noticed something interesting. |
|
@bibo38 as far as i'm aware, the issue is caused by a new cache format being implemented, except this time around we didn't implement one. What @unbiaseduser said is likely the case, and a fix will be out in the near future if I can figure out how to implement one. |
|
Based on the info of @unbiaseduser , that this has to do smth. with the apk shrinking, I've analyzed the cause of the issue. The exception told me about the invalid deserialization of the class 6.2.1package j$.time;
import java.io.Externalizable;
import java.io.InvalidClassException;
import java.io.ObjectInput;
import java.io.ObjectOutput;
import java.io.Serializable;
import java.io.StreamCorruptedException;
final class t implements Externalizable {
private static final long serialVersionUID = -7683839454370182990L;
private byte a;
[...]7.0.0package j$.time;
import j$.time.temporal.ChronoUnit;
import j$.time.temporal.a;Looking for the So the issue is the obfuscation done to the release apk, which renames Classes (and their content fields), which breaks the serialization using Let's look at possible solutions:
Personally I prefer the manual serialization for these few entries of the |
|
Thanks for the input. Anyways, as I mentioned in #50, I created a branch that reworks the serialization mechanism to not use |
|
Thank you both so much, I've been fighting this since launch and I'm so happy this is likely solved. @unbiaseduser, if you want to PR the fix go ahead. |
|
@unbiaseduser I didn't understand, why you merged the cache fix into a special iOS-Branch. As you commented, this would solve this issue in ongoing releases, so why don't add it to the mainline? Could you please explain? |
|
@bibo38 It's completely rewritten and uses a different data format. It would be just straight up incompatible with any previous releases. It's also because of that, that I decided to not mainline it so Kate can work on iOS support (because why jump on the multiplatform train when you don't actually support multiple platforms.). The rationale is that since this is a major breaking change, we might as well take our time to make the app turn over a new leaf(?) as a way to make up for our past |
That's correct, but the current state of the App also has the problem of being incompatible to previous versions due to obfuscations while using the I would be willing to look into adding the necessary migration from the current broken
because it saves work, as you don't need to rebase every time a PR is merged. Given that the plan is to have a shared logic codebase, that doesn't use any Android or iOS specific APIs, you can easily just have this in the master branch. This allows further PRs to separate the logic straight away. The iOS specific things then may be developed in a separate branch and rebasing the branch is much easier, as you only have to patch the iOS codebase.
I agree, that the multiplatform thing is a big feature and doesn't need to be rushed. But the data storage format needs to be reworked in the next release to prevent crashing/lost data due to the obfuscation randomness. Given that the current release has some bugs, where some are already fixed/being fixed in PRs, you want to push these little bugfixes fast to make the user happy. But currently this isn't possible, as it will probably result in a crashing app, if the user has data from previous releases. As I said, I would be willing to create a manual serialization PR with proper migrations to fix this problem, if you don't want to merge the JSON serialization thingy of the iOS release yet. At a later point it is then still possible to migrate the manual serialization to something else, if desired. |
Oh yeah, I briefly forgot that I still have to support migrating from 6.2 to 7.0. My bad. |
|
@unbiaseduser I have attempted to merge your changes (I made the dev branch use multiplatform code even though it lacks iOS support so far, I just wanna get that started) and it doesn't work. This is with a v8.0.0 cache. Am I doing something stupid? |
|
Ah perhaps I am, wait a second |
|
I'm trying to make it so that v9.0.0 will be able to read <=v8.0.0 caches instead of just being forwards compatible, but it's a royal pain with all the classes being changed to their kotlinx.datetime equivalents. Any ideas? |
|
Agh it's just not gonna work |
|
My plan is to:
In the meantime, don't touch the old version yet. This will take quite a while. |
Upgraded from the F-Droid 6.2.1 release and the App crashed on launch.
The App cache was already empty and I don't want to clear the actual data and set it up again 😒 .
Here is the startup exception:
Maybe this issue is related to #48 , but I'm wondering why it's not mentioned in the release notes (or fixed before the F-Droid release), as the Issue seems to be known for about a month.
The text was updated successfully, but these errors were encountered: