[android][tools] fix expo go versioning issues on android (#22950)

# Why

fix expo-go android versioning for sdk 49
close ENG-8955

# How

- [tools] fix for react-native monorepo changes
- [

[android][tools] fix expo go versioning issues on android (#22950)

# Why

fix expo-go android versioning for sdk 49
close ENG-8955

# How

- [tools] fix for react-native monorepo changes
- [tools] update manifest-merger because the original one doesn't support java 17. since the new manifest-merger has kotlin runtime and the jar takes about 35MB. rather than committing a prebuilt jar, now we build manifest-merger from source.
- [tools] since #22609 we don't have `package` in libraries' AndroidManifest.xml, the manifest-merger still requires the `package`, so we have to temporarily put the `package` back during manifest merging. (the `package` name is generated from `namespace` in build.gradle)
- [tools] the original jarjar uses outdated [ASM](https://asm.ow2.io/) and it doesn't support bytecode generated by kotlin. react-native now has some kotlin code, and the original jarjar cannot transform package name from those kotlin classes. i've tried to rebuild a jarjar from [this revision](https://github.com/google/jarjar/commit/e11d5636aa45664271c8f1603067527b2520f591). this requires some manual steps like updating ASM libs and install ant builder. so i still commit the prebuilt jarjar in this pr.
- [updates] force casting for `UpdateEntity` to deal with kotlin smart casting from versioned to unversioned kernel class. (i'll leave inline comment for this)
- [expo-modules-core's `android-annotation`] the project stays in a place that does not support versioning yet. in this pr i just keep it as an unversionable project. cc @lukmccall

# Test Plan

`et add-sdk -p android -s 49.0.0` + android versioned expo-go + sdk 49 NCL smoke test

show more ...

[android] align hermes support integration as ios (#19116)

# Why

close ENG-6275

# How

- instead of parsing bundle header and maintaining the `HERMES_BYTECODE_VERSION` from each react-native

[android] align hermes support integration as ios (#19116)

# Why

close ENG-6275

# How

- instead of parsing bundle header and maintaining the `HERMES_BYTECODE_VERSION` from each react-native upgrade, we should use the `jsEngine` from manifest to determine the js runtime type.
- for reanimated, always use hermes as the runtime for worklets. since we build the `:ReactAndroid:hermes-engine` from source with prefab support, we could just use the prefab integration.
- update versioning script for versioned reanimated + versioned hermes integration.

# Test Plan

`et add-sdk -p android -s 47.0.0` + `./gradlew :app:assembleVersionedDebug` + NCL sdk 47
there were some versioning error from expo-modules-core. i would not include in this pr and will follow up later before versioning for release.

show more ...

[versioning][android] Support react-native 69 (#18032)

* [skip ci] suppoort rn69

* version expo-modules-core

* review feedback + small cleanup

[tools] fix android versioning sed command on macos added '' at the end of filename (#17092)

# Why

from #17074, the android versioning tool will add two single quotes at the end of filename. e.g.

[tools] fix android versioning sed command on macos added '' at the end of filename (#17092)

# Why

from #17074, the android versioning tool will add two single quotes at the end of filename. e.g.
`android/expoview/src/main/java/host/exp/exponent/Constants.java` -> `android/expoview/src/main/java/host/exp/exponent/Constants.java''`

# How

solution refer from https://stackoverflow.com/a/51060063

# Test Plan

`et add-sdk -p android -s 45.0.0`

show more ...

[android] fix versioning on linux (#17074)

[android] Split Expo Go to unversioned and versioned flavors (#12917)

* Add versioning flavors

Extract `flavors.gradle` and fix versioned

* Update manifest based on flavors

* Update fastlan

[android] Split Expo Go to unversioned and versioned flavors (#12917)

* Add versioning flavors

Extract `flavors.gradle` and fix versioned

* Update manifest based on flavors

* Update fastlane build

* Unflavor versioned code

* Update CI to use flavors

* Set default flavor

* Update guides

* Update expotools versioning code

[skip ci]

* [wip] remove flavors from shellapps

* Shell app fallback to `versioned`

* Fix et paths

* Bump `@expo/xdl` in `expotools`

[skip ci]

* Missing uncommitted changes

[skip ci] -expotools yarn.lock, shell app fixes

* Rebase fixes

* Update "Developing Expo Go" guide

[skip ci]

show more ...

[android] pickFirst for only necessary libraries (#13140)

# Why

pickFirst is risky that we will never know which libraries will be picked if duplicated files are from different versions.
in this

[android] pickFirst for only necessary libraries (#13140)

# Why

pickFirst is risky that we will never know which libraries will be picked if duplicated files are from different versions.
in this pr, we try to pick the libraries we really need:

- libfbjni.so
prebuilt library from gradle dependency `extractJNI("com.facebook.fbjni:fbjni:0.0.2")`
- libhermes-inspector.so
- libfolly_futures.so
libraries we didn't rename during sdk publishment before.

fortunately, sdk 39-41 are all based on react native 0.63, so it should not have problems in the meantime.

in the future, only libfbjni.so is needed for pickFirst.
that might still be a risk once we upgrade react native 0.65+ who use the fbjni version.
(somehow we might need to build fbjni ourselves from source or patch old react-native to unify fbjni version)

# How

1. pickFirst for only necessary libraries.
2. add libhermes-inspector.so and libfolly_futures.so to auto renaming list.
3. add sanity check if there are any libraries we didn't rename from versioning.

# Test Plan

1. client-android build pass
2. `et add-sdk -p android` will not show errors

Co-authored-by: Charlie Cruzan <[email protected]>

show more ...

[expotools] workaround for missing so libraries in reactandroid aar

[tools] Move tools/expotools one folder up (#11410)