[android] Drop Android SDK 21 and 22 support (#24201)# Why We are dropping Android SDK 21 and 22 support, we want to use this opportunity to also change the way minSdkVersion and other build.g
[android] Drop Android SDK 21 and 22 support (#24201)# Why We are dropping Android SDK 21 and 22 support, we want to use this opportunity to also change the way minSdkVersion and other build.gradle options which are the same across most of the modules are handled. Right now for each module minSdkVersion is read from the root project properties, if undefined it fallbacks to a default value which is defined on a per-module basis. In the new version we want the option to be configured from a gradle plugin so that it's not necessary to change the fallback value in ~70 files when changing the property. For now the SDK 49 compatibility checks increase amount of boilerplate in the , but with SDK 51 we will be able to remove them and ship modules with a lot less of it. # How Used the gradle plugin as a source of the minSdkVersion compileSdkVersion and targetSdkVersion settings. Settings are applied automatically with the plugin and can be overwritten in the build.gradle of the module. Along with these options lintOptions have been moved to the gradle plugin and two functions were created: useExpoPublising and useCoreDependencies both can be called after the plugin is applied to reduce some of the boilerplate. # Test Plan Tested in Bare Expo and Expo Go on Android SDK 33 and 34 (emulator)
show more ...
[packages] fix react-native 0.73 compatibility [1/3] (#24018)# Why fix react-native 0.73 compatibility. these are for AGP 8 support - https://github.com/react-native-community/discussions-and-pr
[packages] fix react-native 0.73 compatibility [1/3] (#24018)# Why fix react-native 0.73 compatibility. these are for AGP 8 support - https://github.com/react-native-community/discussions-and-proposals/issues/671#issuecomment-1677632448 # How - [packages][bare-expo] set jvm version only if AGP < 8 - [av][dev-launcher] fix AGP 8 non transitive R issue - [dev-client][dev-launcher][dev-menu][core][notifications] fix AGP 8 non default buildConfig issue # Test Plan ci passed in #23961 (https://github.com/expo/expo/pull/23961/checks)
[packages] fix gradle build warnings for gradle 8 (#22537)# Why there are some gradle warnings and will deprecate on gradle 8. since react-native 0.72 upgraded gradle 8, we should deal with thes
[packages] fix gradle build warnings for gradle 8 (#22537)# Why there are some gradle warnings and will deprecate on gradle 8. since react-native 0.72 upgraded gradle 8, we should deal with these warnings. close ENG-7481 # How ``` > Configure project :expo-modules-core WARNING:Software Components will not be created automatically for Maven publishing from Android Gradle Plugin 8.0. To opt-in to the future behavior, set the Gradle property android.disableAutomaticComponentCreation=true in the `gradle.properties` file or use the new publishing DSL. ``` remove the legacy `androidSourcesJar` ``` > Task :expo-constants:createDebugExpoConfig Execution optimizations have been disabled for task ':expo-constants:createDebugExpoConfig' to ensure correctness due to the following reasons: - Gradle detected a problem with the following location: '/Users/user/expo-app/android'. Reason: Task ':expo-constants:createDebugExpoConfig' uses this output of task ':app:checkDebugAarMetadata' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.5.1/userguide/validation_problems.html#implicit_dependency for more details about this problem. ``` remove `create${targetName}ExpoConfig` task inputs and some refactoring of the `get-app-config-android.gradle` # Test Plan ci passed
[core][Android] Generate bindings for custom converters (#21023)# Why Added a way for users to add a custom converter for any type. # How To achieve the desired developer experience, I ut
[core][Android] Generate bindings for custom converters (#21023)# Why Added a way for users to add a custom converter for any type. # How To achieve the desired developer experience, I utilized an annotation processor that produces a connection between user functions that provide a converter and an internal `TypeConverterProvider` class that handles all converters. This connection is established by generating a new class with a single method responsible for invoking the user's implementation. To prevent interference with any existing package, this newly generated class is placed in a prefixed package. However, a downside to this approach is that it has a global impact, as each package will be aware of the converter. # Test Plan Usage: ```kotlin class CustomType { // ... } @ConverterBinder fun converter(): TypeConverter<CustomType> { return object : TypeConverter<CustomType>() { override fun convert(value: Any?): CustomType? { // converter body } } } ```