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