search

itkach / aard2-android

Aard2 for Android, a simple dictionary app
GNU General Public License v3.0
457 stars 97 forks source link

Startup crash when Android 14 regional preferences are set to non-default values #175

Closed buttercookie42 closed 9 months ago

buttercookie42 commented 9 months ago

Android 14 has introduced the ability to set so-called regional preferences for temperature units and the first day of the week ([1], [2]). If I set any of those two settings (just one, or both) to a non-default value, Aard fails to start up. This happened both with 0.53 which I had originally installed (from my old phone's backup), as well as the new 0.55 which I've just installed.

--------- beginning of crash
12-29 16:23:32.662 23422 23422 E AndroidRuntime: FATAL EXCEPTION: main
12-29 16:23:32.662 23422 23422 E AndroidRuntime: Process: itkach.aard2, PID: 23422
12-29 16:23:32.662 23422 23422 E AndroidRuntime: java.lang.ExceptionInInitializerError
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.util.ULocale.toLegacyKey(ULocale.java:3609)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.util.ULocale$JDKLocaleHelper.toULocale(ULocale.java:4324)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.util.ULocale$2.createInstance(ULocale.java:364)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.util.ULocale$2.createInstance(ULocale.java:361)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.impl.SoftCache.getInstance(SoftCache.java:69)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.util.ULocale.forLocale(ULocale.java:429)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:558)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.text.Collator.getInstance(Collator.java:858)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at itkach.slob.Slob$KeyComparator.<init>(Slob.java:1031)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at itkach.slob.Slob$KeyComparator.<init>(Slob.java:1026)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at itkach.slob.Slob$Strength.<init>(Slob.java:228)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at itkach.slob.Slob$Strength.<init>(Slob.java:221)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at itkach.slob.Slob$Strength.<clinit>(Slob.java:205)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at itkach.aard2.BlobDescriptorList.<init>(BlobDescriptorList.java:64)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at itkach.aard2.BlobDescriptorList.<init>(BlobDescriptorList.java:53)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at itkach.aard2.Application.onCreate(Application.java:135)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1317)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7017)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2237)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at android.os.Handler.dispatchMessage(Handler.java:106)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at android.os.Looper.loopOnce(Looper.java:205)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at android.os.Looper.loop(Looper.java:294)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at android.app.ActivityThread.main(ActivityThread.java:8223)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at java.lang.reflect.Method.invoke(Native Method)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:977)
12-29 16:23:32.662 23422 23422 E AndroidRuntime: Caused by: java.util.MissingResourceException: Could not find the bundle com/ibm/icu/impl/data/icudt68b/keyTypeData.res
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundle.java:1205)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.impl.locale.KeyTypeData.initFromResourceBundle(KeyTypeData.java:222)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    at com.ibm.icu.impl.locale.KeyTypeData.<clinit>(KeyTypeData.java:671)
12-29 16:23:32.662 23422 23422 E AndroidRuntime:    ... 27 more
buttercookie42 commented 8 months ago

Somehow the dependency update hasn't made it into the F-Droid build. Maybe because there's no new version tag for the Slobj library, and so F-Droid has continued building with the old version?

itkach commented 8 months ago

Maybe, I don't know, I have nothing to do with F-Droid build. I always treated slobj and slobber as part of the same code base (kind of regret making them separate repos) and build against latest. This is bad for reproducing old builds (which is a non-goal for me) but simplifies things in dev :)

buttercookie42 commented 8 months ago

Their build configuration does seem to reference the version tags so maybe you could still add a new version tag to make them happy? (No idea whether that gets picked up by itself, or whether it requires a new Aard release as well, or whether somebody from the F-Droid team needs to be poked to manually update the dependencies.)

MHBraun commented 8 months ago

Why would somebody try to reproduce old builds? The apks are still out there…

And newer builds are usually an improved version…

Just my 2 cents

From: itkach @. Sent: Donnerstag, 4. Januar 2024 19:38 To: itkach/aard2-android @.> Cc: Subscribed @.***> Subject: Re: [itkach/aard2-android] Startup crash when Android 14 regional preferences are set to non-default values (Issue #175)

Maybe, I don't know, I have nothing to do with F-Droid build. I always treated slobj and slobber as part of the same code base (kind of regret making them separate repos) and build against latest. This is bad for reproducing old builds (which is a non-goal for me) but simplifies things in dev :)

— Reply to this email directly, view it on GitHub https://github.com/itkach/aard2-android/issues/175#issuecomment-1877580217 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYE2S4KSF6RTPBKNDQZEYLYM3ZHHAVCNFSM6AAAAABBG2GU4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGU4DAMRRG4 . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/AAYE2S7MRRDK7IW722MJKO3YM3ZHHA5CNFSM6AAAAABBG2GU4CWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTP5GM3S.gif Message ID: @. @.> >

itkach commented 8 months ago

Their build configuration does seem to reference the version tags so maybe you could still add a new version tag to make them happy?

well, that's an incorrect dependency and should be fixed in the build

buttercookie42 commented 8 months ago

https://gitlab.com/fdroid/fdroiddata/-/issues/3163

jugendhacker commented 8 months ago

Maybe, I don't know, I have nothing to do with F-Droid build. I always treated slobj and slobber as part of the same code base (kind of regret making them separate repos) and build against latest. This is bad for reproducing old builds (which is a non-goal for me) but simplifies things in dev :)

IMHO this is not only bad for binary reproducible builds, but also feature wise it might be hard to reproduce a specific version of the app at any later point. Dependency versions should always be pinned. Especially since the "just use latest master" approach might lead to weird race conditions with F-Droid building it, when you release a new (potentially breaking master of the dependencies, while F-Droid is still trying to build the app version which requires the "old" master)

One possible solution to the problem of having separate repos, might be to include slobj and and slobber as git submodules pinned to specific commits of their respective repos