This fixes the following crash I noticed in the developer console:
```
Exception java.lang.AssertionError:
at com.beemdevelopment.aegis.util.UUIDMap.getByUUID (UUIDMap.java:127)
at com.beemdevelopment.aegis.vault.VaultRepository.getEntryByUUID (VaultRepository.java:229)
at com.beemdevelopment.aegis.ui.fragments.preferences.AuditLogPreferencesFragment.lambda$onViewCreated$0 (AuditLogPreferencesFragment.java:70)
at androidx.lifecycle.LiveData.considerNotify (LiveData.java:133)
at androidx.lifecycle.LiveData.dispatchingValue (LiveData.java:151)
at androidx.lifecycle.LiveData.setValue (LiveData.java:309)
at androidx.lifecycle.LiveData$1.run (LiveData.java:93)
at android.os.Handler.handleCallback (Handler.java:959)
at android.os.Handler.dispatchMessage (Handler.java:100)
at android.os.Looper.loopOnce (Looper.java:232)
at android.os.Looper.loop (Looper.java:317)
at android.app.ActivityThread.main (ActivityThread.java:8592)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:580)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:878)
```
This is another attempt to fix a rare crash we're seeing in the
developer console:
```
Exception android.view.WindowManager$BadTokenException: Unable to add window -- token null is not valid; is your activity running?
at android.view.ViewRootImpl.setView (ViewRootImpl.java:1423)
at android.view.WindowManagerGlobal.addView (WindowManagerGlobal.java:408)
at android.view.WindowManagerImpl.addView (WindowManagerImpl.java:148)
at android.widget.PopupWindow.invokePopup (PopupWindow.java:1583)
at android.widget.PopupWindow.showAsDropDown (PopupWindow.java:1430)
at android.widget.PopupWindow.showAsDropDown (PopupWindow.java:1386)
at com.beemdevelopment.aegis.ui.AuthActivity.lambda$showPasswordReminder$5 (AuthActivity.java:253)
at android.os.Handler.handleCallback (Handler.java:942)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:211)
at android.os.Looper.loop (Looper.java:300)
at android.app.ActivityThread.main (ActivityThread.java:8294)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:580)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1028)
```
This slightly simplifies the approach we use to animate the advanced
entry settings into view, by defaulting its alpha to 0 and setting it to
VISIBLE before the animation starts. That way, we're not dependent on
"animation ended" callbacks that apparently don't fire in all cases.
The XML diff looks a bit scary, but it basically just removes a
wrapping ``RelativeLayout`` that appears to not be necessary.
This fixes an issue introduced by
46e1421c28 where the group chip would not
show after unlocking Aegis. This happened because the activity result is
received *after* ``onStart``. When we were using ``onResume``, it was
the other way around.
Include the '(1.x)' qualifier directly in the import-source selection dropdown to avoid raising false expectations.
See also:
- #1204, where the 1.x-hint was introduced
- #1084: tracking issue for 2.x support
- https://github.com/freeotp/freeotp-android/issues/381
FreeOTP-issue to reconsider the brittle serialised java format used by 2.x
root cause:
the `_prefTitle` is saved in `CharSequence`
solution:
we only able to store `CharSequence` since `Preference.getTitleRes` is removed in AndroidX. As a workaround, we update the title again on Fragment.onStart()
This reduces the chance that we flashbang the user when they launch the
app. The issue remains on older Android versions that don't natively
support dark mode, but I don't think that's fixable.
Activities override the theme based on the user's settings, so this
change only has effect while the app is launching.
This patch addresses the following:
- More consistent offsets between entries in the list, especially in
relation to the action bar and the error card.
- Consistent correct application of card shapes when switching between
favoriting and unfavoriting entries.
- Removal of CompactDividerDecoration. We no longer uses dividers, so
this is no longer needed.
Previously, the dark background colors would not be applied for this
combination of settings.
Unfortunately, I couldn't find a way to avoid some duplication in
themes.xml.
I set CompactDividerDecoration to transparant, because that was already
effectively the case. I think we can remove this class entirely, but
I'll do that in a separate PR.
In rare cases where writing to disk fails after the intro, a crash could
occur if the user presses "Done" again. VaultManager would have been
initialized, and trying to initialize it again would result in a crash.