We have seen apps to be crashing due to multiple System.load calls.
As seen from the log lines:
```
06-01 16:43:41.615 I/LSPosed-Bridge(16031): Caused by: java.lang.UnsatisfiedLinkError: Shared library "/data/app/com.example.sample-some_random_string/base.apk!/assets/lspatch/so/arm64-v8a/liblspatch.so" already opened by ClassLoader 0x1c7(dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.example.sample-some_random_string/base.apk"],nativeLibraryDirectories=[/data/app/com.example.sample-some_random_string/lib/arm64, /data/app/com.example.sample-some_random_string/base.apk!/lib/arm64-v8a, /system/lib64, /product/lib64]]]); can't open in ClassLoader 0x7ffc869ecc(dalvik.system.PathClassLoader[DexPathList[[zip file "/data/user/0/org.houstonmethodist.methodistmobile.debug/cache/lspatch/origin/4198609975.apk", zip file "/data/app/com.example.sample-some_random_string/base.apk"],nativeLibraryDirectories=[/data/app/com.example.sample-some_random_string/lib/arm64, /data/user/0/org.houstonmethodist.methodistmobile.debug/cache/lspatch/origin/4198609975.apk!/lib/arm64-v8a, /system/lib64, /product/lib64]]])
```
Looks like we are trying to load liblspatch.so file even when it was
loaded earlier by the ClassLoader, due to which it is causing the error.
This is similar to this issue:
https://stackoverflow.com/questions/54155086/preventing-duplicate-system-loadlibrary-calls-when-dynamically-loading-reloading
Have added try ... catch block around `System.load` method to handle
exceptions / error raised from it, and have added log line to debug the
issue in cases of actual errors.
Using Map.of here results in compiler optimization generating a class
`a.a` with a method `a` that returns the Map.
The class looks like this (jadx decompilation):
```java
package a;
import java.util.AbstractMap;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import java.util.Objects;
/* loaded from: classes.dex */
public abstract /* synthetic */ class a {
public static /* synthetic */ Map a() {
Map.Entry[] entryArr = {new AbstractMap.SimpleEntry("arm", "armeabi-v7a"), new AbstractMap.SimpleEntry("arm64", "arm64-v8a"), new AbstractMap.SimpleEntry("x86", "x86"), new AbstractMap.SimpleEntry("x86_64", "x86_64")};
HashMap hashMap = new HashMap(4);
for (int i = 0; i < 4; i++) {
Map.Entry entry = entryArr[i];
Object key = entry.getKey();
Objects.requireNonNull(key);
Object value = entry.getValue();
Objects.requireNonNull(value);
if (hashMap.put(key, value) != null) {
throw new IllegalArgumentException("duplicate key: " + key);
}
}
return Collections.unmodifiableMap(hashMap);
}
}
```
For whatever ridiculous reason, on a moto g stylus 5G (2022), when this
method is called in `LSPAppComponentFactoryStub`, the app crashes with
`java.lang.NoSuchMethodError: No static method a()Ljava/util/Map; in
class La/a; or its super classes`. Using a normal HashMap here instead
prevents this optimization from occurring, which prevents the crash.
We are unnecessary fetching original signature even when signature
bypass level is not greater than 0. Due to which some apps which were
not signed were failing to be patched with error "get original signature
failed".
**Description:**
Some apps were failing with reason `Failed to parse Manifest file`
Turns out that `AxmlResourceParser` from `android4Me` is very outdated
and does not work well in all cases.
Hence have removed `axmlprinter` and migrated code to use `AxmlParser`
from `ManifestEditor` by `WindySha`.
Recently encountered Multiple apps where LSPatch failed to parse
AndroidManifest.xml. Upon further debugging found that we throw an error
when style sizes don't adhere to a 4-byte boundary. We can safely ignore
this and move forward since we are anyways not using `block.m_styles`
anywhere in the code. Have checked multiple other AXML parsers wherein
they too do the same thing
XposedBot
Js0n
5ec1cff
LoveSy
Howard Wu
JingMatrix
南宫雪珊
Harshit Shah
AAGaming
Howard Wu
Krishna Suravarapu
Nullptr
LoveSy