V5.0.0e: App suddenly stops on older phone (Samsung A20e)

[jones139]

A few seconds after start-up the app stopped (silent failure, no warnings or beeps).

Disabled Machine Learning algorithm and it is running ok, so something to do with the pytorch model evaluation.

The A20e has 3GB RAM - I wonder if it could be a memory issue. There was nothing helpful in the system logs.

We need to trace what is causing it and at least show an error rather than fail silently before production release of V5.0.

[jones139]

It works on a Samsung A16, which has 4GB of RAM, but is failing silently on a A20e, which has 3GB. It is probably the android system stopping it because it is running out of memory when it tries to load the executorch model.

I think the solution is to check available memory before trying to load the executorch model and not load it if there is insufficient memory - we'll have to add the memory requirement to the model data file, which I think we can get out of the conversion process output.

[jones139]

The RAM idea is incorrect, because it is working fine on a Motorola E13 with only 2GB RAM, and Android 13 'Go' Edition, so the issue is not RAM. Maybe it is about hardware acceleration/optimisation....

[jones139]

I think this user reported crash is similar - at least this one gave us a report rather than failing silently:
***** DEVICE INFO
Brand: samsung
Device: a3y17lte
Model: SM-A320FL
Manufacturer: samsung
Product: a3y17ltexc
SDK: 26
Release: 8.0.0

***** APP INFO
Version: 5.0.0e
Installed On: 2024-03-26 09:42:40
Updated On: 2026-02-20 22:05:40
Current Date: 2026-02-20 23:53:53

***** ERROR LOG
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/uk.org.openseizuredetector-NFfvm4-VX-Hgrx_OQCqQUA==/base.apk"],nativeLibraryDirectories=[/data/app/uk.org.openseizuredetector-NFfvm4-VX-Hgrx_OQCqQUA==/lib/arm, /data/app/uk.org.openseizuredetector-NFfvm4-VX-Hgrx_OQCqQUA==/base.apk!/lib/armeabi-v7a, /system/lib, /system/vendor/lib]]] couldn't find "libexecutorch.so"
at java.lang.Runtime.loadLibrary0(Runtime.java:1011)
at java.lang.System.loadLibrary(System.java:1657)
at com.facebook.soloader.nativeloader.SystemDelegate.loadLibrary(SystemDelegate.java:24)
at com.facebook.soloader.nativeloader.NativeLoader.loadLibrary(NativeLoader.java:52)
at com.facebook.soloader.nativeloader.NativeLoader.loadLibrary(NativeLoader.java:30)
at org.pytorch.executorch.Module.(Module.java:36)
at org.pytorch.executorch.Module.load(Unknown Source:0)
at uk.org.openseizuredetector.alg.SdAlgMl.loadAllActiveModels(SdAlgMl.java:112)
at uk.org.openseizuredetector.alg.SdAlgMl.lambda$initializeAndLoadModels$0$uk-org-openseizuredetector-alg-SdAlgMl(SdAlgMl.java:76)
at uk.org.openseizuredetector.alg.SdAlgMl$$ExternalSyntheticLambda0.onSuccess(D8$$SyntheticClass:0)
at com.google.android.gms.tasks.zzm.run(com.google.android.gms:play-services-tasks@@18.1.0:1)
at android.os.Handler.handleCallback(Handler.java:789)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6944)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)

[jones139]

I think it is because the operating system is 32 bit, but we have a 64 bit version of executorch installed....

So at least we could check if we are running on 32 bit and fail nicely using a method such as this: https://stackoverflow.com/questions/27121199/how-to-know-a-process-of-an-app-is-32-bit-or-64-bit-programmatically-in-android

[jones139]

It looks like the issue on the A20e is different. I have ran it connected to a computer so I can get the full logcat output rather than the logging to file from the app, and we get this error:

2026-02-21 21:09:44.027 19118-19118 libc uk.org.openseizuredetector A Fatal signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x72fdb3eda8 in tid 19118 (seizuredetector), pid 19118 (seizuredetector)

[jones139]

I think this was because the model was optimised to use modern cpu features, such as a dot product instruction (asimddp), which is present on the A16 development device, but not on my A20e production device. This can result in the illegal instruction exception in the native code, leading to the silent failure we are observing.

9462bf0 introduces a check of an extra (optional) field in the model index: "min_cpu_features": ["dotprod"], which will check that the CPU has the desired features.
We need to set the required features manually based on how we convert the pytorch model to the executorch format.

With these changes, the model still runs correctly on the newer A16, and we get a warning on the A20e that we have no compatible models available.

[jones139]

This should be fixed now (well, the app should fail nicely rather than crashing silently anyway) - I'll keep this issue open until a few more people have tested V5.0.0f though to be sure.