Status Update
No update yet.
Comments
ch...@gmail.com
We use build flavours heavily with a lot of common code. The refactoring support in AS is really good but it continually catches us out when it doesn't work across all flavours in a project. It's a big gap for serious product development.
uc...@google.com
We at my company need this same feature. We have a lot of white labels and need refactor the same class across flavours. :(
ch...@gmail.com
I need this feature too...
ch...@gmail.com
+1 My company also need this feature.
ch...@gmail.com
Can we atleast know the status of the issue please? Will it be fixed or is it in low priority. It's been 4 years.
ch...@gmail.com
We are currently investigating possibly solutions.
je...@google.com
+1 This will exclude a lot of unnecessary work. In my work I have 25 flavours. :(
jr...@squareup.com
+1 .. we need it as well...
ch...@gmail.com
Any update on this?
ch...@gmail.com
We also need this feature...please...
cm...@google.com
I would like to vote for this feature as well.
hu...@google.com
+1
cm...@google.com
Build flavor source code is useless until this is fixed.
hu...@google.com
+1
ch...@gmail.com
+1
cm...@google.com
+1 "Build flavor source code is useless until this is fixed." - agree
re...@gmail.com
+1
re...@gmail.com
My team are heavy users of Android Flavours and the IDE remaining semantically aware of all flavours besides the currently 'focused' one, for refactoring and searching purposes, would be a major productivity boost.
Indeed, the current state almost feels like flavours are only partially supported in the IDE.
Indeed, the current state almost feels like flavours are only partially supported in the IDE.
hu...@google.com
We are investigating this issue. In the mean time, the workaround is to set android.enableAapt2=false in your gradle.properties file.
cm...@google.com
im...@google.com
We have a fix pending, waiting for the next build tools release.
Description
supply all required information.
Studio Build:
Version of Gradle Plugin: 2.2.3
Version of Gradle: 2.14.1
Version of Java: 1.8
OS: Centos7
Steps to Reproduce:
Hi：
We found when we build the android project, sometime the daemon process will exit during the packageRelease on our build server (Centos 7 with 8G RAM). Below is the error log.
:PrivateDoctor_Main:mergeReleaseJniLibFolders
:PrivateDoctor_Main:transformNative_libsWithMergeJniLibsForRelease
:PrivateDoctor_Main:validateSigningRelease
:PrivateDoctor_Main:packageRelease
----- End of the daemon log -----
FAILURE: Build failed with an exception.
* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
But in local build (MAC or Windows with 8G ) it fine. We thought it may cause by memory. Because on build server may have many build process at same time.
We config:
build tool version : 25.0.1
dexOptions {
javaMaxHeapSize "3g"
}
org.gradle.daemon=true
org.gradle.jvmargs=-Xmx3584m
I want to know, how many memory will be consumed when build. 3G+3.5G? So the unexpected exit may caused by this?
Thanks!