A few days ago, due to some reasons, the project Android SDK was upgraded from 28 to 29, and OKHttp was upgraded from 3.x to 4.9. Hidden dangers are approaching step by step.

JavaSDKVersion: 1.8, compileSdkVersion: 28 -> 29, buildToolsVersion: "28.0.0" -> "29.0.3", minSdkVersion: 15, targetSdkVersion : 28 -> 29,Copy the code

What’s wrong with Android 8.0 phones? What’s wrong with Android 10 phones

Fix problem: Change targetSdkVersion to the original 28

Cause of occurrence: there is no time for the moment, and then see what reason

compileSdkVersion

CompileSdkVersion tells Gradle which Android SDK version to use to compile your app. It is used purely at compile time. When you change compileSdkVersion, new compile warnings, compile errors, etc. (you should really fix these warnings, they are there for a reason). It is important to note that modifying compileSdkVersion does not change runtime behavior. CompileSdkVersion is not packaged into APK but used at compile time

It is therefore highly recommended that you always compile with the latest SDK. Use the latest SDK build checking on your own code (Lint?) There are many benefits to avoiding the use of the latest deprecated API and preparing for the use of the new API

Note that if you use the Support Library, compiling with the latest SDK is required to use the newly released Support Library. Typically, a new version of the Support Library is released with a new system release, providing compatibility Support for new apis and features added to the system. For example, to use the Support Library version 23.1.1, compileSdkVersion must be at least 23.

minSdkVersion

MinSdkVersion is the minimum version required for an application to run. MinSdkVersion is one of the flags the Google Play Store uses to determine whether an app can be installed on a user’s device.

MinSdkVersion also plays an important role in development: Lint runs in your project by default and will warn you if you use an API higher than minSdkVersion, helping you avoid runtime problems of calling non-existent apis. If certain apis are only used on a later version of the system, it is usually resolved by checking the system version at runtime.

Keep in mind that the libraries you are using may have their own minSdkVersion. The minSdkVersion of your application must be greater than or equal to the minSdkVersion of these libraries. For example, if you have three libraries whose minSdkVersion is 4, 7, and 9, your minSdkVersion must be at least 9 to use them. In rare cases where you still want to use a library that is higher than the minSdkVersion you are applying (handle all edge cases and make sure it is only used on newer platforms), you can use the Tools :overrideLibrary tag, but do a thorough test!

targetSdkVersion

TargetSdkVersion is the main method for Android system to provide forward compatibility. What does that mean? As The Android system upgrades, the behavior of an API or module may change, but to ensure that APK behaves the same as before. As long as the targetSdkVersion of the APK is unchanged, even if the APK is installed on the new Android system, its behavior remains the same as that of the old system, thus ensuring forward compatibility with the old application.

After Android 4.4 (API 19), the behavior of the set() and setRepeat() apis of AlarmManager has changed. Prior to Android 4.4, both apis were set to exact times, and the system was guaranteed to wake Alarm at the point in time set by the API. Due to power saving reasons, Android 4.4 system realizes AlarmManager alignment wake-up. The system considers the wake-up time set by these two apis as an inaccurate time, and the system can only guarantee to wake up at a certain time after the time you set.

At this point, although the API does not change at all, the actual behavior of the API does change if the API is used in APK and the behavior in the application relies heavily on AlarmManager to wake up at a precise time, such as the alarm application. If The Android operating system is not compatible, the old APK installed on the new system phone, there will be problems.

How does Android guarantee this compatibility? This is when targetSdkVersion comes into play. When APK calls set() or setRepeat() of AlarmManager, the system will first check the targetSdkVersion information of the called APK. If the value is less than 19, the system will continue to set the exact wake-up time. If not, perform the new behavior.

Modifying the targetSdkVersion behavior of APK changes and requires complete testing

buildToolsVersion

Android build tool version, install the selected version in SDK Manager, buildToolsVersion>=CompileSdkVersion; Higher-version build-Tools can build lower-version compiled Android applications

Gradle and SDK versions

MinSdkVersion and targetSdkVersion are packaged by Gradle into the final APK file, Androidmanifest.xml

A little bit more specific here