Androidmanifest. xml considerations

1. Target SDK version
Android runtime and Dalvik decide whether to work in the "compatibility mode" based on the target SDK version. The so-called compatibility mode is to disable various new mechanisms and experience optimization statuses in the new version. If targetsdkversion is set to low, all new features and Mechanisms of the later version are disabled, including "screen adaptation" and "Hardware acceleration 』.
To ensure compatibility of each version and use new features in a timely manner, targetsdkversion is continuously improved with the release of the latest Android version to ensure a complete experience on all Android devices.
Not targeting the latest versions of Android; compatibility modes apply. Consider testing and updating this version. Consult the Android. OS. Build. version_codes javadoc for details
Ii. debuggable = "true" in <Application>"
When debuggable is enabled, the SDK tools (including proguard) will not be optimized for the released version, except for being more vulnerable to attacks, for example, removing Code Debug information (symbol name, line number, etc.) to remove debug and verbose-level log output. These have a direct impact on the capacity and performance of the app release version.
Avoid hardcoding the debug mode; leaving it out allows debug and release builds to automatically assign one
Iii. <uses-Permission> after <Application>
On the surface, there is no problem, but some hidden risks that <Application> Internal Attributes take effect correctly are hidden.
The <Application> tag shocould appear after the elements which declare which version you need, which features you need, which libraries you need, and so on. in the past there have been subtle bugs (such as themes not getting applied correctly) when the <Application>
Tag appears before some of these other elements, so it's best to order your manifest in the logical dependency order