Feature Request P1
Status Update
No update yet.
Comments
al...@google.com
da...@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.
pa...@prsolucoes.com
We at my company need this same feature. We have a lot of white labels and need refactor the same class across flavours. :(
vi...@gmail.com
I need this feature too...
mi...@gmail.com
+1, I need this very badly
ad...@elucid-mhealth.com
+1 My company also need this feature.
al...@google.com
mu...@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.
xa...@google.com
We are currently investigating possibly solutions.
am...@gmail.com
+1 This will exclude a lot of unnecessary work. In my work I have 25 flavours. :(
mu...@gmail.com
+1 .. we need it as well...
mu...@gmail.com
Any update on this?
le...@gmail.com
We also need this feature...please...
dt...@duolingo.com
I would like to vote for this feature as well.
uc...@google.com
di...@google.com
an...@gmail.com
+1
th...@gmail.com
Build flavor source code is useless until this is fixed.
al...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
si...@gmail.com
+1 "Build flavor source code is useless until this is fixed." - agree
ro...@gmail.com
+1
[Deleted User] <[Deleted User]>
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.
Description
OS version: Windows 7 64 bits
Java JRE/JDK version: JDK 1.7u52
I'm not sure if this was posted before, I searched and could not find any other issues.
If you have a base class in your main folder, lets say a common abstract activity which you implement with your custom changes in each flavor. Now AS will select one of the flavors as the "current" one. Let's suppose that you make a considerable change in your base activity, like changing the parameters in a function that is overridden by the flavors. AS can refactor automatically this kind of changes, but in case of flavors it will only refactor the "current" flavor. leaving all other flavors to be manually edited. And if that wasn't enough, you have to switch flavors and wait for the resynch to finish.
I know you should not have all flavors "active" at the same time since there could be code collisions, but it would be nice to make AS flavor aware even if the flavors are "hidden" they should be taken into account when this kind of refactoring happens.
This also applies for renames of classes that modify the Android Manifest. Only the main and "current" flavor's manifests will be changed. Leaving you with a nice runtime error instead of a compile time error that the activity is missing.
Thanks.