search

Fox2Code / FoxMagiskModuleManager

A module manager for Magisk because the official app dropped support for it
GNU Lesser General Public License v3.0
2.19k stars 131 forks source link

App Not Opening #310

Closed sunmughan closed 1 year ago

sunmughan commented 1 year ago

Device: OnePlus 9 I've just updated the app to the newer version 2.0.1 and the app is not opening thereafter. Tried installing v7a, and v8a as well but still the same result. Screenshot_2023-04-28-10-42-15-22_115a3d4b87870cbbc4a93f5a8407539f

androidacy-user commented 1 year ago

Duplicate of #305

f000bar commented 1 year ago

Of course people didn't read the changelog. A changelog is for understanding what features have changed - the expectation is that the app will otherwise continue to work as expected, and any inconsistent settings state would be handled by the app itself.

This could have been avoided by added a version table/file. If it exists (and isn't too old) nothing to change. If it doesn't, wipe the database, initialize, and write the version. At the very least the app could detect whatever incorrect state it's in, and rather than displaying nothing, show a "please wipe your data" message.

androidacy-user commented 1 year ago

Of course people didn't read the changelog. A changelog is for understanding what features have changed - the expectation is that the app will otherwise continue to work as expected, and any inconsistent settings state would be handled by the app itself.

This could have been avoided by added a version table/file. If it exists (and isn't too old) nothing to change. If it doesn't, wipe the database, initialize, and write the version. At the very least the app could detect whatever incorrect state it's in, and rather than displaying nothing, show a "please wipe your data" message.

I assure you every possible solution was explored and none was found, and any such table would have been unreadable anyway due to encryption changes.

In addition, it is not unusual for changelogs to list incompatibilities, breakages, etc, especially for a major version bump.

Do not assume that just because something doesn't work as you expected that we did not try to find a solution. And do not blame us when you don't read the changelog our website editor took the time out of their day to write.

f000bar commented 1 year ago

Encryption? You're in control of that. I just looked at /data/data/com.fox2code.mmm/shared_prefs/com.fox2code.mmm_preferences.xml, and the language/country preferences are all in plaintext ... on both versions of the app.

I did not blame you, I said there are always options. Do not blame us - the users - for missing something that was confusingly communicated and easily missed, or expecting us to read through something we're likely to expect to just work - because that's the expectation set by 99.9% of apps. Plan for your users to be lazy.

The upgrade notice in the app took us straight to the releases page in github, and the APKs: https://github.com/Fox2Code/FoxMagiskModuleManager/releases/tag/v2.0.1 There could have been a note about clearing data there, but there was not.

That page had a link to the changelog: https://www.androidacy.com/magisk-module-manager-v2-0-1/ a 500 word affair that (1) leaves the comparability note until the very end - after a plug for membership, and (2) says "you may need to clear app data" when to read it here sure makes it sound like everyone will. It's also not technically a changelog, it's high-level release notes.

Both sides have some responsibility here, it's not an either-or. Could users have done a better job? Absolutely. Could the team have been clearer in their communication? Also yes.

androidacy-user commented 1 year ago

We're not playing this game. We apologize for the inconveniences this caused but we do not intend to reverse our stance on encrypting everything viably encryptable.

FoxMMM offers a very attractive attack vector and an unfortunate side effect of encrypting shared preferences (where encryption is under our control and not under the control of external libraries or the system) so that malicious modules can't manipulate them is the app is crashing too early in the application lifecycle, and instead of the system letting our crash handler - that we do in fact have in place - catch the resulting crash, it just stubbornly keeps restarting the app without showing anything to the user, resulting in an ANR instead of a proper crash.

For far too long, apps with root access have taken the stance that since you have root security is moot and have not taken security seriously. We don't intend to follow that flawed logic.

In addition we do follow semantic versioning, and incremented the major version code due to potential and expected breakages.

That being said I will mention something to our editor about potentially editing the wording of the warning in the release notes in our next meeting.

With everything said, I'm locking this issue because I don't feel anything productive is going to come out of it continuing. I may unlock it in a few days.