In Android development, buildconfig. DEBUG is used to check whether it is in DEBUG mode and perform special operations that are only enabled in DEBUG mode, such as printing logs. This has the advantage of not having to actively change it before Release, since this value is true in Debug mode and false in Release mode.
Problem 1.
Buildconfig. Debug will always be false in Debug mode if the application has only one Module. If you now have two modules, App and Lib, and App depends on Lib, there is a utility class LogUtils in Lib, and the code is as follows:
When we call LogUtils in the App Module we will find that we will never be able to print logs because buildConfig.debug will always be false. Why is that?
Reason 2.
Buildconfig. Java is generated automatically at compile time, and a copy is generated for each Module, with the packageName of that Module being the packageName of BuildConfig. Java. So if your application has multiple modules it will generate multiple buildconfig. Java, and the above Lib Module imports its own buildconfig. Java, Buildconfig.debug will always be true as a result of the fact that compile-time dependent modules provide releases by default to other modules or projects.
3. Solutions
Based on the above analysis, we have two ideas at present:
(1) Always call BuildConfig for the last Module to run, because it is not dependent on any other Module, so buildconfig. DEBUG is accurate.
(2) Make the dependent Module provide a version other than Release.
3.1 Solution one: Use another buildconfig.java
It would be ok if the Lib Module could import to the outer layer and actually run the App BuildConfig as follows:
Reflection gets the BuildConfig of the Module that is actually executed, which is called in its own Application:
AppUtils.syncIsDebug(getApplicationContext());
That seems to have done the trick.
However, if you look closely, this solution is still problematic because buildConfig. Java’s packageName is the Package Name of the Module, which is the Package attribute in Androidmanifest.xml. Context.getpackagename () yields the applicationId, which can be changed with build.gradle. So when the applicationId in build.gradle is inconsistent with the package attribute in Androidmanifest.xml, the reflection lookup classpath above will fail.
PS: . This scheme has a variant is through the android app. ActivityThread. CurrentPackageName get package name, eliminating pass the Context initialization steps, However, there are still instances where the applicationId has been modified and the class cannot be found.
3.2 Solution 2: Lib publishNonDefault
Having a dependent Module provide a version other than the Release version requires adding to all dependent libraries:
android {
publishNonDefault true
}
Indicates that the Module does not use the default configuration, which will package other versions, including Debug versions. Add libraries to the App Module one by one as follows:
dependencies {
releaseCompile project(path: ‘:library’, configuration: ‘release’)
debugCompile project(path: ‘:library’, configuration: ‘debug’)
}
Represents a dependency Module that depends on different versions.
However, this approach requires all Module configurations to be modified and is too intrusive.
3.3 Final solution: Use ApplicationInfo.flag_DEBUggable
Since BuildConfig doesn’t work, let’s decompile the Debug and Release packages to see if there are any other differences, You’ll notice that the Android :debuggable value of the application node in their Androidmanifest.xml is different. The Debug package value is false and the Release package value is true, which is automatically changed by compilation. So we consider using this property of ApplicationInfo to determine whether it is a Debug version, as follows:
Call initialization within your own Application,
AppUtils.syncIsDebug(getApplicationContext());
This can be determined later by calling apputils.isdebug (), as in LogUtils above. This works with modules that are Lib and applicationId modified, much more reliably than buildConfig.debug.
Note that android:debuggable cannot be actively set in your App Module, otherwise both the Debug and Release versions will always be set to the same value. Of course, there is no need for automatic setting.
Below is the advertisement of sponsor 100offer
There is no shortage of job opportunities for good people, only good opportunities for themselves. But they often don’t have the energy to sift through a sea of opportunities to find the best fit.
100Offer will strictly screen talents and enterprises on the platform, so that “the best talents” and “the best companies” meet.
Scan the QR code below to register 100Offer and talk about your expectations for your next job. Within a week, you’ll receive 5-10 great opportunities to meet your needs!
