Status Update
Comments
do...@gmail.com <do...@gmail.com> #2
Branch: main
commit 6dc78fbbbbadac9c2dc2065150a7af2422c6115c
Author: Rupert Ben Wiser <bewise@chromium.org>
Date: Thu Sep 12 16:16:14 2024
webview: Add support configuration for CHIPS
Adding a boundary interface to let Android developers configure
if partitioned cookies should be enabled or not.
go/chips-android-apis-webview
Bug: 364904765
Change-Id: I683ab5ec157a11aa081db5763380e692ab02c5e6
Reviewed-on:
Reviewed-by: Peter Pakkenberg <pbirk@chromium.org>
Auto-Submit: Rupert Wiser <bewise@chromium.org>
Commit-Queue: Peter Pakkenberg <pbirk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1354607}
M android_webview/expectations/system_webview_32_64_bundle.AndroidManifest.expected
M android_webview/expectations/system_webview_32_bundle.AndroidManifest.expected
M android_webview/expectations/system_webview_64_bundle.AndroidManifest.expected
M android_webview/expectations/system_webview_bundle.AndroidManifest.expected
M android_webview/expectations/trichrome_webview_32_64_bundle.AndroidManifest.expected
M android_webview/expectations/trichrome_webview_32_bundle.AndroidManifest.expected
M android_webview/expectations/trichrome_webview_64_32_bundle.AndroidManifest.expected
M android_webview/expectations/trichrome_webview_64_bundle.AndroidManifest.expected
M android_webview/expectations/trichrome_webview_bundle.AndroidManifest.expected
M android_webview/glue/java/src/com/android/webview/chromium/AndroidXProcessGlobalConfig.java
M android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java
M android_webview/nonembedded/java/AndroidManifest.xml
M android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/ProcessGlobalConfigConstants.java
M chrome/android/expectations/monochrome_32_64_public_bundle__base.AndroidManifest.expected
M chrome/android/expectations/monochrome_32_public_bundle__base.AndroidManifest.expected
M chrome/android/expectations/monochrome_64_32_public_bundle__base.AndroidManifest.expected
M chrome/android/expectations/monochrome_64_public_bundle__base.AndroidManifest.expected
M chrome/android/expectations/monochrome_public_bundle__base.AndroidManifest.expected
xa...@android.com <xa...@android.com>
ph...@gmail.com <ph...@gmail.com> #3
There is already test coverage of CHIPS behavior inside of Chromium in
Due to limitations of AndroidX test infra, manual test instructions are necessary to exercise the toggling of the enable partitioned cookies API. WebView toggles CHIPS behavior with the disable-partitioned-cookies
command line switch.
To demonstrate the API's correctness in toggling this, log statements were inspected when this flag was toggled during WebView startup.
See the diff below for details:
diff --git a/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java b/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java
index 63c5f5a5b2795..ee589176bdab2 100644
--- a/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java
+++ b/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java
@@ -490,6 +490,9 @@ public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
if (!androidXConfig.getPartitionedCookiesEnabled()) {
cl.appendSwitch("disable-partitioned-cookies");
+ Log.e(TAG, "Partitioned cookies disabled");
+ } else {
+ Log.e(TAG, "Partitioned cookies enabled");
}
// Now safe to use WebView data directory.
do...@gmail.com <do...@gmail.com> #4
Note: Will add testing when more of the API has been implemented.
ph...@gmail.com <ph...@gmail.com> #5
Project: platform/frameworks/support
Branch: androidx-main
Author: Adam Walls <
Link:
[WebView] Add API to configure CHIPS
Expand for full commit details
[WebView] Add API to configure CHIPS
This adds an API to allow Android developers to configure CHIPS globally. This is done with ProcessGlobalConfig. In order to prevent this from being published/used prior to Android B's release, RestrictTo annotation is used.
Design: go/chips-android-apis-webview
Test: Will add testing in a follow-up CL.
Bug: 364904765
Change-Id: If6d630562be7209eb2ab00da2dbad9398ba0553e
Files:
- M
webkit/webkit/src/main/java/androidx/webkit/ProcessGlobalConfig.java
- M
webkit/webkit/src/main/java/androidx/webkit/WebViewFeature.java
- M
webkit/webkit/src/main/java/androidx/webkit/internal/StartupFeatures.java
- M
webkit/webkit/src/main/java/androidx/webkit/internal/WebViewFeatureInternal.java
Hash: 4fe72afdcf64cad8b2399ca7a28d1aa57a05f976
Date: Thu Oct 24 17:35:26 2024
ph...@gmail.com <ph...@gmail.com> #6
Project: platform/frameworks/support
Branch: androidx-main
Author: Adam Walls <
Link:
Refactor common Webkit test classes into test.common module.
Expand for full commit details
Refactor common Webkit test classes into test.common module.
This is intended to enable new androidx.webkit test targets so that we
do not need to use the Orchestrator annotation to create new test
processes. This is intended as a refactor to reduce the CL size in
aosp/3371538.
The new androidx.webkit.test.common module was created using
the development/project-creator/create_project.py script.
Test: ./webkit/run_instrumentation_tests.sh
Bug: 364904765
Change-Id: If68173a88bd5267d3aa19986ba3f4486d9e17b64
Files:
- M
settings.gradle
- A
webkit/integration-tests/common/build.gradle
- M
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/PollingCheck.java
- A
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/TestWebMessageListener.java
- M
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/WebViewOnUiThread.java
- M
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/WebkitUtils.java
- M
webkit/integration-tests/instrumentation/build.gradle
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/AsyncStartUpTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/CookieManagerCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/MultiProfileTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/PostMessageTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/ProxyControllerTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/ServiceWorkerClientCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/ServiceWorkerWebSettingsCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/TracingControllerTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebSettingsCompatDarkModeTestBase.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebSettingsCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebSettingsCompatUserAgentMetadataTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebStorageTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewClientCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewDocumentStartJavaScriptTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewRenderProcessClientTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewRenderProcessTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewWebMessageCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewWebMessageListenerTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/internal/AssetHelperTest.java
- M
webkit/integration-tests/instrumentation/src/androidTestTargetSdk32/java/androidx/webkit/WebSettingsCompatForceDarkTest.java
- M
webkit/integration-tests/instrumentation/src/androidTestTargetSdkLatest/java/androidx/webkit/WebSettingsCompatDarkThemeTest.java
- M
webkit/integration-tests/instrumentation/src/androidTestTargetSdkLatest/java/androidx/webkit/WebSettingsCompatLightThemeTest.java
Hash: 463387393fce755928325a57d49cec218631a6a3
Date: Fri Dec 13 23:24:49 2024
xa...@android.com <xa...@android.com> #7
Project: platform/frameworks/support
Branch: androidx-main
Author: Adam Walls <
Link:
[WebView] Add CHIPS testing via integration tests.
Expand for full commit details
[WebView] Add CHIPS testing via integration tests.
In order to test the enable partitioned cookies API added in
aosp/3318854, integration tests are added.
Note: Since test process restarts are not supported, and the startup
APIs can only be called once per process lifetime, this will avoid
errors by only testing with a single test case that covers a few
use cases.
Test: ./webkit/run_instrumentation_tests.sh
Bug: 364904765
Change-Id: I89354cb04bb92b954a5a51fac06133ebd6a3ae3a
Files:
- M
settings.gradle
- A
webkit/chips-enabled-integration-tests/instrumentation/build.gradle
- A
webkit/chips-enabled-integration-tests/instrumentation/src/androidTest/AndroidManifest.xml
- A
webkit/chips-enabled-integration-tests/instrumentation/src/androidTest/java/androidx/webkit/EnablePartitionedCookiesTest.java
- M
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/WebViewOnUiThread.java
- M
webkit/run_instrumentation_tests.sh
Hash: 200afa93c09543d6c7320a025fed7f2944689055
Date: Thu Dec 12 03:20:20 2024
[Deleted User] <[Deleted User]> #9
Project: platform/frameworks/support
Branch: androidx-main
Author: Adam Walls <
Link:
Reformat affected classes from aosp/3406800.
Expand for full commit details
Reformat affected classes from aosp/3406800.
aosp/3406800 refactored some common classes that were not formatted
properly.
Bug: 364904765
Test: ./webkit/run_instrumentation_tests.sh
Change-Id: I328af103b753e575c25a383dd709e355a973b98f
Files:
- M
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/PollingCheck.java
- M
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/TestWebMessageListener.java
- M
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/WebViewOnUiThread.java
- M
webkit/integration-tests/common/src/main/java/androidx/webkit/test/common/WebkitUtils.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/AsyncStartUpTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/MultiProfileTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/PostMessageTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/ProxyControllerTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/ServiceWorkerClientCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/ServiceWorkerWebSettingsCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/TracingControllerTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebSettingsCompatDarkModeTestBase.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebSettingsCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebSettingsCompatUserAgentMetadataTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebStorageTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewClientCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewDocumentStartJavaScriptTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewRenderProcessClientTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewRenderProcessTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewWebMessageCompatTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/WebViewWebMessageListenerTest.java
- M
webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/internal/AssetHelperTest.java
Hash: 818530aa0c71b1b6e1cba00a39494794b45ed6c8
Date: Wed Dec 18 00:18:27 2024
[Deleted User] <[Deleted User]> #10
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.webkit:webkit:1.13.0-alpha03
dm...@gmail.com <dm...@gmail.com> #11
Project: chromium/src
Branch: main
Author: Adam Walls <
Link:
[WV] Fix adding switch to stale command line reference.
Expand for full commit details
[WV] Fix adding switch to stale command line reference.
Currently, the disable-partitioned-cookies, aka
kDisablePartitionedCookiesSwitch, is used to control CHIPS in WebView.
However, it is currently broken because it uses a stale reference to the
command line object. This is because it is called after the point in
WebView's startup where the native library is loaded and passes off its
command line switches in Java to the native equivalent. This causes
changes that make the old reference stale. It results in an incongruence
between Java and native command line switches, causing undefined and
unintended behavior with CHIPS in WebView.
This fixes this by using the getInstance method to get a fresh reference
to a valid instance of the command line. Another change limits the scope
of the object that caused the issue by adding a block around the code
that references it. Note: The default behavior will be set to on for
now, postponing the decision to change it at a later point.
testing for the glue layer later.
Low-Coverage-Reason: HARD_TO_TEST Though we are looking into adding
Bug: 364904765, 389121692
Test: See bug 389121692 for test instructions.
Change-Id: Icd9a04bbdc3a82197bf27bec428e60f05cd62243
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6171228
Auto-Submit: Adam Walls <avvall@chromium.org>
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Commit-Queue: Adam Walls <avvall@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1413072}
Files:
- M
android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java
Hash: fda51784ebf6743fdd47c1e6fc441fdb05d13945
Date: Wed Jan 29 11:42:08 2025
sh...@gmail.com <sh...@gmail.com> #12
Issue still not fixed.
Directory ./build/exploded-bundles contains *.aar files in release mode.
But it should has two subdirectories with corresponding *.aar files:
./build/exploded-bundles/debug/
./build/exploded-bundles/release/
xa...@android.com <xa...@android.com> #13
As I mentioned a while ago, there is work to be done in Gradle itself, and this hasn't happened yet.
sa...@gmail.com <sa...@gmail.com> #14
xa...@android.com <xa...@android.com> #15
ne...@gmail.com <ne...@gmail.com> #16
pa...@gmail.com <pa...@gmail.com> #17
ma...@gmail.com <ma...@gmail.com> #18
The WHOLE POINT of debug and release builds is to have debug/release overrides. satur9n above is correct really, when he says that the new android gradle build system doesn't support android projects which depend on android libraries. (since it doesn't distinguish properly between debug and release, it DOES NOT SUPPORT Android Libraries!).
We too MUST wait until this issue is fixed before we can migrate our developers to Android Studio, much as we would like to.
vi...@gmail.com <vi...@gmail.com> #19
Workarounds are dangerous, and may lead to release unwanted code.
And by the way, it would be so perfect that buildTypes get propagated through other modules
wo...@gmail.com <wo...@gmail.com> #20
[Deleted User] <[Deleted User]> #21
ja...@gmail.com <ja...@gmail.com> #22
an...@gmail.com <an...@gmail.com> #23
My configuration:
gradle 1.10
android gradle plugin 0.9.1
compileSdkVersion = 19
buildToolsVersion = "19.0.0"
There is not way to compile the application and the libraries along with it having different BuildConfig, however, it is possible to build the libraries separately and export them as android archives (.aars).
I included an Android project with two libraries and the gradle scripts with defined two flavours: one building the libraries along with the application at compile time and one giving to the application a reference to an external library where the libraries have been previously built and exported as aars.
P.S.
I had first to export the libraries as aars and then enable the flavour using them (i.e. uncommenting it).
ma...@gmail.com <ma...@gmail.com> #24
[Deleted User] <[Deleted User]> #25
Details:
ma...@gmail.com <ma...@gmail.com> #26
The difference is that we have made the release library into a debug library by virtue of switching the Java code to debug, as long as it uses the BuildConfig.RELEASE variable?
So actually, Android Gradle is still using the release AAR, but we don't care!
[Deleted User] <[Deleted User]> #27
se...@gmail.com <se...@gmail.com> #28
ma...@gmail.com <ma...@gmail.com> #29
bi...@gmail.com <bi...@gmail.com> #30
android {
publishNonDefault true
...
}
and this in the project that uses it
dependencies {
releaseCompile project(path: ':theotherproject', configuration: 'release')
debugCompile project(path: ':theotherproject', configuration: 'debug')
}
Taken from here:
[Deleted User] <[Deleted User]> #31
Error:Configuration with name 'release' not found.
xa...@android.com <xa...@android.com> #32
Using publishNonDefault with Flavors makes things more complicated because the library publishes all combinations, so you'll need to specific flavor1Debug instead of just debug. This does not scale well.
[Deleted User] <[Deleted User]> #33
/**
* Gets a field from the project's BuildConfig. This is useful when, for example, flavors
* are used at the project level to set custom fields.
* @param context Used to find the correct file
* @param fieldName The name of the field-to-access
* @return The value of the field, or {@code null} if the field is not found.
*/
public static Object getBuildConfigValue(Context context, String fieldName) {
try {
Class<?> clazz = Class.forName(context.getPackageName() + ".BuildConfig");
Field field = clazz.getField(fieldName);
return field.get(null);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
return null;
}
To get the `DEBUG` field, for example, just call this from your `Activity`:
boolean debug = (Boolean) getBuildConfigValue(this, "DEBUG");
I have also answered this on StackOverflow:
da...@gmail.com <da...@gmail.com> #34
[Deleted User] <[Deleted User]> #36
[Deleted User] <[Deleted User]> #37
pa...@gmail.com <pa...@gmail.com> #38
[Deleted User] <[Deleted User]> #39
ar...@gmail.com <ar...@gmail.com> #41
sp...@gmail.com <sp...@gmail.com> #42
public abstract boolean isBuildConfigDebug();
In BaseApplication I also have a static variable: private static boolean mIsDebug;
with access to the variable via a method:
public static boolean isDebug() {
return mIsDebug;
}
Then in BaseApplication I override onCreate and the first thing I do is call:
mIsDebug = isBuildConfigDebug();
Then instead of using BuildConfig.DEBUG in the library application, I call BaseApplication.isDebug();
Yes it's hacky, but it's easy, and I haven't had any issues with it.
[Deleted User] <[Deleted User]> #43
V1 with Debug/Release API keys is more of a challenge. The map api keys are embedded in layouts, which should be specified for Debug and Release resources separately. The issue is that the debug resources are not being built on a debug app, and you can't work around that so easily. (this is not a challenge, don't sweat it!)
ma...@gmail.com <ma...@gmail.com> #44
do...@gmail.com <do...@gmail.com> #45
ma...@gmail.com <ma...@gmail.com> #46
ma...@gmail.com <ma...@gmail.com> #47
ma...@gmail.com <ma...@gmail.com> #48
da...@gmail.com <da...@gmail.com> #49
basically you need to rewrite on the fly the Application.mk of your module from the build.gradle of your main app.
In the attachment there is my build.gradle of my main build.gradle (stripped down from the extra stuff)
WARNING: in the module i build the jni lib using a custom Application.mk that NEEDS to have these lines inside it
###################################################################################
# THIS FILE IS MODIFIED BY ndkUpdateApplicationMk
# ANY CHANGE TO THESE LINES WILL BE OVERWRITTEN @ NEXT COMPILE
APP_ABI :=
APP_OPTIM :=
NDK_DEBUG :=
###################################################################################
It's a kind of a dirty hack, but it works for me and it could be easily adapted to work with the split-apk feature too.
PS: i am not sure that NDK_DEBUG could be specified inside the Application.mk, but worth a try (i don't need it).
[Deleted User] <[Deleted User]> #50
do...@gmail.com <do...@gmail.com> #51
dependencies {
appFlavor1ReleaseCompile project(path: ':libraryProject', configuration: 'libFlavor3Release')
appFlavor1DebugCompile project(path: ':libraryProject', configuration: 'libFlavor3Debug')
appFlavor2ReleaseCompile project(path: ':libraryProject', configuration: 'libFlavor7Release')
appFlavor2DebugCompile project(path: ':libraryProject', configuration: 'libFlavor7Debug')
appFlavor3ReleaseCompile project(path: ':libraryProject', configuration: 'libFlavor1Distribute')
appFlavor3DebugCompile project(path: ':libraryProject', configuration: 'libFlavor1Release')
}
Notice that in example there is different number of flavors and build types in library and app so automatic forwarding of build types makes actually no sense. We want release version of app flavor 1 to depend on release version of lib flavor 3 and we want the release version of app flavor 3 to depend on distribute version of lib flavor 1.
Can't the fix simply be by generating DSL methods for every buildType - flavor combination in dependencies object? This is already done for every build type (you get debugCompile and releaseCompile) and for every flavor (you get flavor1Compile etc.). Why is so complicated to create all combinations (flavor1DebugCompile)? Why is this issue not resolved for almost two years now?
do...@gmail.com <do...@gmail.com> #52
Map<String, Dependency> customDeps = new HashMap<String, Dependency>()
customDeps.put("appFlavor1DebugCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor1Debug"))
customDeps.put("appFlavor1ReleaseCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor1Release"))
customDeps.put("appFlavor2DebugCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor3Debug"))
customDeps.put("appFlavor2ReleaseCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor3Release"))
customDeps.put("appFlavor3DebugCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor5Debug"))
customDeps.put("appFlavor3ReleaseCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor5Release"))
configurations.all() {config ->
Dependency d = customDeps.get(
if(d != null) {
config.dependencies.add(d)
}
}
An example gradle project is attached in this comment.
However, there is now another bug to address: I've already reported it in
For example, in attached zip you can execute task :app:assembleAppFlavor1Debug and you will end up executing all following tasks:
$ ./gradlew :app:assembleAppFlavor1Debug
:app:preBuild
:app:preAppFlavor1DebugBuild
:app:compileAppFlavor1DebugNdk
:app:checkAppFlavor1DebugManifest
:app:preAppFlavor1ReleaseBuild // why is this task reached
:app:preAppFlavor2DebugBuild // why is this task reached
:app:preAppFlavor2ReleaseBuild // why is this task reached
:app:preAppFlavor3DebugBuild // why is this task reached
:app:preAppFlavor3ReleaseBuild // why is this task reached
... and now all flavors of library are built
do...@gmail.com <do...@gmail.com> #53
do...@gmail.com <do...@gmail.com> #54
an...@gmail.com <an...@gmail.com> #55
[Deleted User] <[Deleted User]> #56
Main:
task wrapper(type: org.gradle.api.tasks.wrapper.Wrapper) {
gradleVersion = '1.9'
}
Module (theotherproject):
buildscript {
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0'
}
}
apply plugin: 'com.android.library'
...
if you got
"Cannot evaluate module theotherproject : Configuration with name 'debug' not found."
you are missing the
android {
publishNonDefault true
...
}
wa...@gmail.com <wa...@gmail.com> #57
sc...@gmail.com <sc...@gmail.com> #58
je...@google.com <je...@google.com>
zh...@gmail.com <zh...@gmail.com> #59
m....@gmail.com <m....@gmail.com> #60
yu...@google.com <yu...@google.com> #61
hu...@gmail.com <hu...@gmail.com> #62
It's been two years !!!!
[Deleted User] <[Deleted User]> #63
I couldn't identify any related issues on
Variant Aware Dependency Management
ap...@gmail.com <ap...@gmail.com> #64
he...@163.com <he...@163.com> #65
mo...@bbva.com <mo...@bbva.com> #66
in...@gmail.com <in...@gmail.com> #67
bu...@gmail.com <bu...@gmail.com> #68
af...@gmail.com <af...@gmail.com> #69
be...@google.com <be...@google.com> #70
vi...@gmail.com <vi...@gmail.com> #71
With this bug ANY development with linked library module is PRACTICALLY IMPOSSIBLE.
mr...@gmail.com <mr...@gmail.com> #72
cc...@gmail.com <cc...@gmail.com> #73
sh...@gmail.com <sh...@gmail.com> #74
For example:
--------------------------------
gradle.properties
SNAPSHOT=true
--------------------------------
build.gradle
subprojects {
android {
defaultConfig {
String snapshot = (Boolean.valueOf(getProperty('SNAPSHOT').toString())) ? "Boolean.parseBoolean(\"true\")" : "false"
buildConfigField 'boolean', 'SNAPSHOT', snapshot
}
}
}
--------------------------------
SomeWhere.java
import static com.yourcompany.library.BuildConfig.SNAPSHOT;
void f() {
if (SNAPSHOT) {
Log.v(LOG_TAG, "This code will be kicked out by compiler when SNAPSHOT=false");
}
}
--------------------------------
Now when you building release apk, just override this property:
./gradlew assembleRelease -PSNAPSHOT=false
Btw, following this approach you may keep SNAPSHOT=true if needed to test release apk with verbose logs.
vi...@gmail.com <vi...@gmail.com> #75
vi...@gmail.com <vi...@gmail.com> #76
vi...@gmail.com <vi...@gmail.com> #77
vi...@gmail.com <vi...@gmail.com> #78
Gradle is just bloated piece of crap, just like Android as a whole. And Google doesn't care, because it monetizes on ads in cheap phones, not on quality and good apps.
sh...@gmail.com <sh...@gmail.com> #79
sh...@gmail.com <sh...@gmail.com> #80
Almost all authors above are using BuildConfig.DEBUG field which is always false due to this issue.
I propose to define custom field and control it manually.
This approach works fine for my goals:
- remove useless log-messages from binaries
- add more checks (like strict-mode) for debug mode only
vi...@gmail.com <vi...@gmail.com> #81
ma...@gmail.com <ma...@gmail.com> #82
#83, this solution only is a replacement for the DEBUG flag in BuildConfig, but there can be many differences between the release and debug build types, e.g. ProGuard or different source files or assets.
To workaround the issue define a property in gradle.properties:
buildType=debug
And use it for the defaultPublishConfig field, e.g. in the main build.gradle:
subprojects {
android {
defaultPublishConfig properties['buildType']
}
}
This way the debug build type of the libraries is published during development. If you want to do a release build just add -PbuildType=release to the build command. Note that with this solution you can't do a debug and a release build with a single command.
ma...@gmail.com <ma...@gmail.com> #83
This is by far the most starred issue for Subcomponent-Tools-Gradle, so please don't ask us to lower our expectations and instead put more effort into fixing this. And also make the process more transparent and provide us more information, like links to related Gradle issues, instead of just delaying the fix again and again.
vi...@gmail.com <vi...@gmail.com> #84
My complex iOS project written in Objective-C that contains my library and several third-party libraries compiles incrementally IN 6 SECOND. SIX, CARL!
Gradle, on other side, compiles much simpler project incrementally for over 30 seconds on the same machine.
After polished and fast iOS development process I hate slow, bulky and unresponsive Android build tools, emulator and eternal buggy API.
This Issue Ticket is an example that Google cannot for over 2 years to fix most important of bugs.
DIE, Android! I'm writing for you only because every teenager without money doesn't have any other smartphone choice. I hope Microsoft will make good cheap phones and Google will have to fix all this Gradle crap (and Android's Bluetooth too).
bo...@gmail.com <bo...@gmail.com> #85
vi...@gmail.com <vi...@gmail.com> #86
I can link you TENS of other (more specific, but no less stupid) bugs about what Google doesn't care.
In Bluetooth:
In Audio:
In WiFi:
Basically, EVERY system framework on Android DOESNT WORK CORRECTLY. This is insane for iOS developer like me. :) I'm accustomed to situation when if you have system framework and documentation for it, it is working with maybe with 1-2 small bugs or small corner cases.
There is 3-year old article about this:
bo...@gmail.com <bo...@gmail.com> #87
ep...@gmail.com <ep...@gmail.com> #88
do...@gmail.com <do...@gmail.com> #89
do...@gmail.com <do...@gmail.com> #90
I think it would be best to let developers choose for each build type the build type of every dependency. Currently there is a hackish way of achieving that (see my
I hope that Android Gradle team will fix
aa...@gmail.com <aa...@gmail.com> #91
de...@gmail.com <de...@gmail.com> #93
se...@mobiquite.fr <se...@mobiquite.fr> #94
#60 works fine but works only for 1 dependency lib (=if you need to specify a configuration to only 1 sub-lib "mylibrary")
What I need is to include several libs as following:
customDeps.put("appFlavor1DebugCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor1Debug"))
...
customDeps2.put("appFlavor1DebugCompile", dependencies.project(path: ":mylibrary2", configuration: "libFlavor1Debug"))
I've succeeded in adding 2 dependencies to the same
Name: appFlavor1DebugCompile
Dependencies: [DefaultProjectDependency{dependencyProject='project ':mylibrary'', configuration='debug'}, DefaultProjectDependency{dependencyProject='project ':mylibrary2'', configuration='default'}]
But at compilation, it includes only the first lib (mylibrary) and then failed to find classes/methods of the second lib (mylibrary2)...
DodoEnte...@gmail.com (or someone else) do you have any solution?
Thanks.
ni...@gmail.com <ni...@gmail.com> #97
gradle 2.9
android gradle plugin 1.3.0
compileSdkVersion = 20
buildToolsVersion = "23.0"
Best work around I found was to configure ProGuard to keep needed debugging information. I found the solution here :
A fix for this would be very appreciated.
pa...@gmail.com <pa...@gmail.com> #98
trying to use
dependencies {
flavorDebugCompile project([path: ':custom_lib', configuration: "libraryDebug"])
It gives the following error:
flavorDebugCompile method not found
[Deleted User] <[Deleted User]> #99
custom_library build.gradle:
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
}
^ yes the above will always use the releaseCompile so this is actually pointless BUT .. future proof
app module that depends on library build.gradle:
dependencies {
compile (project(':custom_library')) {
exclude group: 'com.squareup.leakcanary'
}
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
}
[Deleted User] <[Deleted User]> #101
Error:(278, 0) Gradle DSL method not found: 'debugCompile()'
Possible causes:The project 'AndroidFleksy' may be using a version of Gradle that does not contain the method.
Open Gradle wrapper file The build file may be missing a Gradle plugin.
nu...@gmail.com <nu...@gmail.com> #102
lo...@gmail.com <lo...@gmail.com> #103
lo...@gmail.com <lo...@gmail.com> #105
Android Studio 2.1 RC
Gradle 2.10
I have very similar issue. Whenever I'm adding external dependency by using
dependency {
compile 'com.corp:corp-api:0.1.1-SNAPSHOT'
}
new, very strange task appears, the name of task is like:
:lib2:prepareComCorpCorpApi011SNAPSHOTLibrary
which depends on
:lib1:bundleLibraryDebug
:lib1:bundleLibraryRelease <<<<<<<<<<<<-----
So it does not matter which kind of build I'm running, release of debug (or flavored ones), anyway all the build types are fired...
Any ideas ?
an...@gmail.com <an...@gmail.com> #106
Can't believe it's been 2 years and it's still not fixed!
I don't want DEBUG code in the final shared library or Java code, but only trick is to use a variable, hence all codes gets in release APKs if I don't manually edit the gradle file. Pretty shitty if you ask me.
an...@gmail.com <an...@gmail.com> #107
Lib's build.gradle (uses experimental gradle 0.7.0):
model {
android {
...
productFlavors {
create('all') {
...
}
}
publishNonDefault true
}
}
configurations {
allDebug
allRelease
}
App's build.gradle (uses standard gradle 2.1.0):
debugCompile project(path: ':lib', configuration: 'allDebug')
releaseCompile project(path: ':lib', configuration: 'allRelease')
I'm pretty sure the productFlavors in the lib's gradle is not needed if using debug/release configurations only.
e....@gmail.com <e....@gmail.com> #108
ge...@gmail.com <ge...@gmail.com> #109
sr...@gmail.com <sr...@gmail.com> #110
cp...@gmail.com <cp...@gmail.com> #111
Probably not important, but my library is external though linked inside project as described here:
tr...@gmail.com <tr...@gmail.com> #112
ul...@gmail.com <ul...@gmail.com> #113
build.gradle (lib):
---------------------------------------------------------------------
apply plugin: 'com.android.library'
android {
publishNonDefault true
...
buildTypes {
release {
...
}
debug {
...
}
}
}
dependencies {
...
}
---------------------------------------------------------------------
build.gradle (application)
---------------------------------------------------------------------
apply plugin: 'com.android.application'
android {
...
buildTypes {
release {
...
}
debug {
...
}
}
}
dependencies {
debugCompile project(path: ':libName', configuration: "debug")
releaseCompile project(path: ':libName', configuration: "release")
...
}
ss...@gmail.com <ss...@gmail.com> #114
xa...@google.com <xa...@google.com> #115
[Deleted User] <[Deleted User]> #117
ne...@gmail.com <ne...@gmail.com> #118
xa...@google.com <xa...@google.com> #119
lb...@gmail.com <lb...@gmail.com> #120
How could it be fixed?
bu...@gmail.com <bu...@gmail.com> #121
m....@gmail.com <m....@gmail.com> #122
I'm wondering if there different behavior between using local library vs. using an (maven) aar dependency. Because the code inside an aar is already compiled - the gradle plugin would need to change the java bytecode of the BuildConfig class.
ss...@gmail.com <ss...@gmail.com> #123
xa...@google.com <xa...@google.com> #124
fo...@googlemail.com <fo...@googlemail.com> #125
a....@gmail.com <a....@gmail.com> #126
xa...@google.com <xa...@google.com> #127
bi...@gmail.com <bi...@gmail.com> #128
file or directory '/home/user/StudioProjects/ProjectName/app/src/debug/kotlin', not found
file or directory '/home/user/StudioProjects/ProjectName/app/src/main/kotlin', not found
file or directory '/home/user/StudioProjects/ProjectName/app/src/debug/kotlin', not found
bi...@gmail.com <bi...@gmail.com> #129
je...@google.com <je...@google.com> #130
kh...@gmail.com <kh...@gmail.com> #131
kh...@gmail.com <kh...@gmail.com> #132
n1...@gmail.com <n1...@gmail.com> #133
Trying to set flags depending on build type - release flags works all the time
ra...@gmail.com <ra...@gmail.com> #134
pi...@gmail.com <pi...@gmail.com> #135
ge...@gmail.com <ge...@gmail.com> #136
ke...@gmail.com <ke...@gmail.com> #138
hu...@gmail.com <hu...@gmail.com> #139
publishNonDefault is deprecated and has no effect anymore. All variants are now published.
and looking at the source code it seems to be useless, however, the warning message seems to be wrong as I still use the debug variant can't
public void setPublishNonDefault(boolean publishNonDefault) {
logger.warn("publishNonDefault is deprecated and has no effect anymore. All variants are now published.");
}
Description
Gradle plugin does not propagate whether you are doing a debug build or a release build to a dependent android library.
VERSION INFORMATION:
gradle plugin: 0.3
gradle: 1.4
SETUP:
/rootFolder
/rootFolder/androidProject
/rootFolder/androidLibraryProject
rootFolder -> settings.gradle
include 'androidProject'
include 'androidLibraryProject'
androidProject -> build.gradle
apply plugin: 'android'
dependencies {
compile project(':androidLibraryProject')
}
androidLibraryProject -> build.gradle
apply plugin: 'android-library'
STEPS TO REPRODUCE:
cd /rootFolder
gradle assembleDebug
EXPECTED RESULTS:
...
:androidLibraryProject:compileDebug
...
:androidProject:compileDebug
...
ACTUAL RESULTS:
...
:androidLibraryProject:compileRelease
...
:androidProject:compileDebug
...