I’m not talking about modernization using what’s in the new version of Android, so today I’m talking about three main areas:
1. Non-sdk interfaces restrict some of the evolutions in Android Q. I hope developers remove the restrictions on non-SDK interfaces.
2. Sixty-four applications, is to hope that you can provide your application as soon as possible sixty-four version;
3. TargetSdkVersion, which means that people upgrade their application’s targetSdkVersion to a newer system version number.
Interface limits
Non-sdk interfaces affect application compatibility
Then, as a general rule, we started with restrictions on non-SDK interfaces that developers rarely used, and we used targetSdkVersion to differentiate the extent of restrictions and give developers more time to adapt. We have also added some new open architecture support for developers who have legitimate needs, such as putting these interfaces into the open SDK to fully guide developers away from relying on non-SDK interfaces.
The basic principle of
However, in Android Q, the list has evolved to the point that the meanings of the blacklist, light grey list and white list are the same as before.
However, the dark grey list is divided into two categories. One is equivalent to the social list for P, which we call the social list for P. That is to say, when your targetSdkVersion reaches P or above, these interfaces are no longer usable, they are equivalent to the blacklist. There is also an additional social list called For Android Q, which is equivalent to a blacklist when applied to targetSdkVersion on Android Q or above.
For example, an interface whose annotations only contain unsupporteapospusage and no maxTargetSdk parameter is in the grey list. If the maxTargetSdk parameter is zero, or if the entire line is an opinion, that is, if there is no private API annotation, or if there is an annotation line with the maxTargetSdk parameter is zero, then the interface is blacklisted. If the maxTargetSdk parameter is, for example, Android P, then the interface is accessible when the TargetSdk model is applied below P or Android P, but is not accessible at Q.
See from the menu on the right to have a one piece from gray list to move into the inside of the blacklist interface list, and we are not only is lists all from the list will be along to the interface in the blacklist, and each interface behind those comments, there is a red will tell developers say you should switch to another public interface. Below is a list of interfaces that have been moved from the grey list to the whitelist. So if your application in the Android P use an interface, has now been moved to the blacklist for example, if that is a very strong demand for you, and what do you think is a reasonable demand, then you can have a link to clarify reason through the document, can go to apply for a public interface, This link takes you directly to our public Buganizer, which means you’ve just sent a bug directly to the Android product team.
So the first two are dynamic detection methods, which are very accurate, but their coverage may not be very high, and they need to depend on which test cases you run. So we also provide a static detection tool called Veridex (which is open source and has its source code directly in AOSP, as well as pre-compiled versions for each platform and will be updated with each Android Q Beta release). With this tool you can just run a command, check your APK files, and it will scan all APK files for non-SDK interfaces, but of course it has some limitations because it’s a static inspection tool, like it can’t detect JNI calls, It then diagnostic of reflection calls may not be one hundred percent accurate, he might say when you are in a very complex operation to joining together out of a string you want reflection interface when they don’t know the final result of patchwork interface about what kind of, or do you have a level of reflecting the calling code, though it is seems to be the reflection calls, But actually it’s a dead code, then it will light up, says you may call the SDK interface here, but in fact in your application, because it is fast, so may not be invoked, so even though he has these limitations, but because it is a static testing, so the test efficiency is very high, you also do not need the test case, So it’s able to it’s able to provide more code coverage, so you can combine static and static detection with dynamic detection to see what non-SK interfaces your application is using.
