I was getting the following compilation errors when I pulled in this repo.
```
error: unmappable character for encoding ASCII
```
The root cause seems to be the character below was not from the ASCII set.
Add suport to gradle 4.10.1 or high!
The new version of android studio 3.3 recommendete to update gradle project to 4.10.1
> To take advantage of the latest features, improvements, and security fixes, we strongly recommend that you update the Android Gradle plugin to version 3.3.0 and Gradle to version 4.10.1. [Release notes ](https://developer.android.com/studio/releases/gradle-plugin)
>Android plugin 3.2.0 and higher now support building the Android App Bundle—a new upload format that defers APK generation and signing to compatible app stores, such as Google Play. With app bundles, you no longer have to build, sign, and manage multiple APKs, and users get smaller, more optimized downloads. [Learn more](https://developer.android.com/guide/app-bundle/?utm_source=android-studio)
but if the upgrade to the new Android gradle warning come up, becouse was obsoleted
> WARNING: API 'variant.getJavaCompile()' is obsolete and has been replaced with 'variant.getJavaCompileProvider()'.
> It will be removed at the end of 2019.
> For more information, [see ](https://d.android.com/r/tools/task-configuration-avoidance.)
> To determine what is calling variant.getJavaCompile(), use -Pandroid.debug.obsoleteApi=true on the command line to display a stack trace.
Changelog:
----------
[Android] [Deprecated] - fix warinings obsolete to update to gradle 4.10.1 or high
Test Plan:
----------
change gradle-wrapper.proprerties:
`- distributionUrl=https\://services.gradle.org/distributions/gradle-4.4-all.zip`
`+ distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.1-all.zip`
and in build.gradle
` - classpath 'com.android.tools.build:gradle:3.2.0'`
`+ classpath 'com.android.tools.build:gradle:3.3.0'`
for warnnings starts, use this change and fix the problem! =)
This fixes crash on Expo client which is wrapping Activity prior to passing it as a context to the root view.
After my recent change in the logic on how we access main activity we know extract the reference to it using `getContext` from the root view. Previously we were using `getTopLevelActivity` which wasn't working well in the cases where other non-react-native activities were transitioning in or out. The new approach however turned out not to be the best as for example expo client does not pass activity instance as a context directly to the root view. Instead the activity class is wrapped in ContextThemeWrapper ([see it here](41458d1de9/android/expoview/src/main/java/versioned/host/exp/exponent/ReactUnthemedRootView.java (L13))).
We now try to unwrap the context if it is not a fragment activity using `getBaseContext`
This fixes https://github.com/expo/expo/issues/3191
This change makes us reach to fragment manager only when screen container is attached to window (and therefore we are sure that the current activity is react one). The problem reported in #33 was due to the fact we'd do that when container is instantiated which does not necessarily mean that react activity is in foreground. We didn't need to actually access fragment manager while not in foreground so this change removes fragmentManager as a member and we get it directly from context when needed.
Supposedly fixes#33
This change adds an ability for screen container on Android to apply the correct mechanism for transparent layer blending. This is specifically important as screens are usually a complex views that may displays many layers and while transitioning often opacity is used to animate these. When we detect screen transitioning we (a) turn on offscreen alpha compositing (which makes the opacity being applied for the whole screen layer at once instead of making all the children semi-transparent) and also (b) turn on hardware layer that makes offscreen compositing render to GPU (which is both faster and consumes only GPU memory).
In addition to that change we also need to disable wrapping Screen's children with View, as in such a case opacity is applied on the underlying View instead of a Screen. That workaround has been added because of a bug in Animated library and fixed in RN 0.57+
