Fixed
Status Update
Comments
uc...@google.com <uc...@google.com> #2
These changes would be really nice! Being able to change the text colour is really important as it now doesn't match the rest of our app either.
Stack overflow posting -http://stackoverflow.com/questions/32533069/how-to-change-a-title-color-in-chrome-custom-tabs
Stack overflow posting -
je...@google.com <je...@google.com>
ga...@google.com <ga...@google.com> #3
Changing text color and the overflow icon color is important to us too! Awesome work on the feature though.
ga...@google.com <ga...@google.com> #4
The ability of customize the status bar color is very important!
ha...@googlemail.com <ha...@googlemail.com> #5
It is in the essence of a "custom" UI component to have a custom color. Please add this feature!
ha...@googlemail.com <ha...@googlemail.com> #6
I have noted that the status bar automatically generated from the toolbar color is a bit darker than needed. The status bar color of the chrome activity is different to the one of the rest of my app. It doesn't strictly follow Material guidelines.
ha...@googlemail.com <ha...@googlemail.com> #7
The same issue I met. And is there a way to customize the title? using my own title rather than the url's. Thanks
je...@google.com <je...@google.com>
ga...@google.com <ga...@google.com> #8
Would very appreciate this enhancement!
ma...@gmail.com <ma...@gmail.com> #9
I'd love to have the possibility to change title text color, I'll be a very important graphic consistency inside my app
ga...@google.com <ga...@google.com> #10
Voting +1 for this feature.
ma...@gmail.com <ma...@gmail.com> #11
It has been more than a year. Please add this!
ma...@gmail.com <ma...@gmail.com> #13
It will certainly be a nice feature and have a nice title for the chrome tab. Please fix this.
ma...@gmail.com <ma...@gmail.com> #14
Customize the status bar color is a real need. Voting +1
ga...@google.com <ga...@google.com> #15
Yes, it's needed definitely. Please!! Voting+1.
ga...@google.com <ga...@google.com> #16
Any date to the release of this feature? Working with VectorDrawables is awesome and let us have an IconKit but this little impediment make it not perfect
je...@google.com <je...@google.com> #17
Voting +1 for this feature.
ga...@google.com <ga...@google.com> #18
Voting +1 for this feature.
ma...@gmail.com <ma...@gmail.com> #19
voting +1 for this feature
ga...@google.com <ga...@google.com> #20
Voting +1 for this feature.
ma...@gmail.com <ma...@gmail.com> #21
Voting +1 for this feature.
ga...@google.com <ga...@google.com> #22
+1 from me. I really need this feature.
ma...@gmail.com <ma...@gmail.com> #23
+1 from me. I've to fallback my implementation to webview because of this graphic inconsistency.
ga...@google.com <ga...@google.com> #24
Voting +1 for this feature.
ma...@gmail.com <ma...@gmail.com> #25
Voting +1 for this feature.
ga...@google.com <ga...@google.com>
ma...@gmail.com <ma...@gmail.com> #26
Voting +1 for this feature.
ga...@google.com <ga...@google.com> #27
Not being able to set a proper dark or light statusbar/toolbar icon color is breaking our app color design very bad.
+1 for this feature.
+1 for this feature.
jw...@gmail.com <jw...@gmail.com> #28
Voting +1 for this feature.
ga...@google.com <ga...@google.com> #29
Estoy de acuerdo con este comentario, es molesto cuando el diseñador te levanta la mano porque no le convence el contraste de los colores y te es imposible responder con fundamento y suplir los criterios. Sería genial poder personalizar más esta sección.
dr...@gmail.com <dr...@gmail.com> #30
This has been an issue for 6 years now. Why isn't Google dealing with it? If I'm to use Custom Tabs, I need to be able to change the toolbar text and color at will.
jw...@gmail.com <jw...@gmail.com> #31
ช่วยแก้ไข browser ให้ผมหน่อยครับ
dr...@gmail.com <dr...@gmail.com> #32
Yeah, definitely. We're not planning to upgrade until 3.0 is stable, but I'm worried that it will get to the stable channel without this being fixed. If legacy multidex support for test apks is ready before 3.0 is stable, then I don't have a problem :)
ma...@gmail.com <ma...@gmail.com> #33
Hello,
since the multidex 1.0.2 is live I would expect that multidex works fine on api <21 for test apks, but this is not the case.
Did I misunderstand something when you said this will be backported to legacy multidex so test apk can contain multiple dex files also or?
classpath 'com.android.tools.build:gradle:3.0.0-alpha7'
multidex : '1.0.2',
Android Studio 3.0 Canary 7
Build #AI-171.4182969, built on July 14, 2017
JRE: 1.8.0_152-release-884-b01 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.4
since the multidex 1.0.2 is live I would expect that multidex works fine on api <21 for test apks, but this is not the case.
Did I misunderstand something when you said this will be backported to legacy multidex so test apk can contain multiple dex files also or?
classpath 'com.android.tools.build:gradle:3.0.0-alpha7'
multidex : '1.0.2',
Android Studio 3.0 Canary 7
Build #AI-171.4182969, built on July 14, 2017
JRE: 1.8.0_152-release-884-b01 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.4
ga...@google.com <ga...@google.com> #34
The support for legacy multidex test apks has been merged in AOSP, but a new version of com.android.support:multidex has not been published yet. We need this artifacts published in order to add support for legacy multidex test apks in the Android plugin for Gradle.
ma...@gmail.com <ma...@gmail.com> #35
Hello,
Thank you for the answer but I don't understand what is inside multidex 1.0.2 then.
in support lib Revision 25.4.0 it is stated:
Concurrent with this support library release, we are also releasing multidex version 1.0.2. This version includes the following important changes:
Allows multidexing of instrumentation APK.
Deprecates MultiDexTestRunner (AndroidJUnitRunner should be used instead).
We use multidex 1.0.2. Does this mean this fix will come out in 1.0.3, do you have any eta window on this topic?
Cheers
Thank you for the answer but I don't understand what is inside multidex 1.0.2 then.
in support lib Revision 25.4.0 it is stated:
Concurrent with this support library release, we are also releasing multidex version 1.0.2. This version includes the following important changes:
Allows multidexing of instrumentation APK.
Deprecates MultiDexTestRunner (AndroidJUnitRunner should be used instead).
We use multidex 1.0.2. Does this mean this fix will come out in 1.0.3, do you have any eta window on this topic?
Cheers
ga...@google.com <ga...@google.com> #36
Indeed, 1.0.2 contains all the necessary support, but the support in the plugin is missing. I will try to get the plugin changes published in the next few preview releases, but I cannot give any hard guarantees when it will happen.
ma...@gmail.com <ma...@gmail.com> #37
Thank you for the clarification. Could you please update the documentation that the new support/ multidex lib is not integrated in tooling yet. Also in gradle build files lint recommends removing the "dev" flavor since it is not needed anymore but then it would break tests, instant run etc. also an important thing to note.
Looking forward to the integration let us know when you manage to merge it.
Have a nice weekend!
Looking forward to the integration let us know when you manage to merge it.
Have a nice weekend!
ga...@google.com <ga...@google.com> #38
I am reopening this, as we have too many reports. It is blocked on internal issue b/62286076 .
ma...@gmail.com <ma...@gmail.com> #39
hello, what is the current progress of this issue?
thank you
thank you
ga...@google.com <ga...@google.com> #40
@39 The support in the plugin is ready, however we need a new version of build tools published. Hopefully that will happen soon.
ma...@gmail.com <ma...@gmail.com> #41
this is amazing news, could you please update the status of this ticket when this happens?
does this mean this will come out with beta4?
does this mean this will come out with beta4?
ga...@google.com <ga...@google.com> #42
Build tools are published independently of the plugin and Android Studio, but I hope that will happen in the next week or two. I'll update the bug once it happens.
ja...@gmail.com <ja...@gmail.com> #43
@42 1.0.2 does provide support for multidex android test APKs.
Simply create a "CustomerTestRunner" and override "onCreate" to call "MultiDex.installInstrumentation(context, targetContext)". See this example:https://github.com/jaredsburrows/android-gif-example/blob/master/src/androidTest/kotlin/test/CustomTestRunner.kt#L12 .
Simply create a "CustomerTestRunner" and override "onCreate" to call "MultiDex.installInstrumentation(context, targetContext)". See this example:
ja...@gmail.com <ja...@gmail.com> #44
It seems that multidex 1.0.2 works with multidex test apks for AGP 2.3.0, not 3.0.0+.
yo...@gmail.com <yo...@gmail.com> #45
#44 Make sure you use ATSL runner 1.0.1 or later.
st...@gmail.com <st...@gmail.com> #47
We discovered this problem too. It's quite annoying for us and we will have to reverse switching to GAP 3 if there is no fix in the next 2 days...
Can anyone give us an update and an ETA for this ?
We use build tools 26.0.1, gap 3 beta 5, ASTL runner 1.0.1.
Can anyone give us an update and an ETA for this ?
We use build tools 26.0.1, gap 3 beta 5, ASTL runner 1.0.1.
st...@gmail.com <st...@gmail.com> #48
As a workaround, how can we run proguard on the instrumentation apk, when it is not enabled in our debug variant for the main app ?
ja...@gmail.com <ja...@gmail.com> #49
You do not want to proguard a debug apk. It would take forever to write and
run new tests.
Jared Burrows
*jaredsburrows@gmail.com <jaredsburrows@gmail.com>*
LinkedIn:https://www.linkedin.com/in/jaredsburrows
On Thu, Sep 14, 2017 at 12:14 PM, <buganizer-system@google.com> wrote:
run new tests.
Jared Burrows
*jaredsburrows@gmail.com <jaredsburrows@gmail.com>*
LinkedIn:
On Thu, Sep 14, 2017 at 12:14 PM, <buganizer-system@google.com> wrote:
dr...@gmail.com <dr...@gmail.com> #50
Until this issue is fixed, many apps will have no choice but to proguard their test apk :)
st...@gmail.com <st...@gmail.com> #51
I agree, this workaround is not a good solution.
st...@gmail.com <st...@gmail.com> #52
On our side, we fixed the issue by cutting down on our dependencies in the instrumentation apk. Though the dex count is still in the red zone and we will be happy to see the issue fix, but there is no more emergency on our side.
je...@google.com <je...@google.com> #53
ja...@gmail.com <ja...@gmail.com> #54
I see it is tracked in Moma. Is this set for marked release for 3.0.0-beta7? or release?
[Deleted User] <[Deleted User]> #55
was the fix included in the latest release of build tools 26.1? I think the link to track the release is not public.
za...@gmail.com <za...@gmail.com> #56
It still doesn't work for me on 3.0.0-beta7 and Build tools 26.0.2 - I still get the error.
[Deleted User] <[Deleted User]> #57
Status says fixed but could we get instructions on how to make it work? Is this already included in Build tools 26.0.2 and AGP 3.0.0-beta7?
le...@gmail.com <le...@gmail.com> #58
Same problem here... I don't see this issue as fixed
ga...@google.com <ga...@google.com> #59
The issue has not been fixed in beta7, as build tools 26.0.2 are missing some of the pieces to have this working. Re-opening.
ja...@gmail.com <ja...@gmail.com> #60
Thank you.
vy...@pinterest.com <vy...@pinterest.com> #61
Is there an ETA? Looks like build tools 27.0.0 shipped without this fix.
cm...@google.com <cm...@google.com>
gl...@fitbit.com <gl...@fitbit.com> #62
Any ETA on this? Or which components we should watch for updates? Is the the build tools 2x.0.y? Is it a new multidex support lib 1.0.3? 3.1 plugin?
cm...@google.com <cm...@google.com> #63
Sorry, we don't commit to timelines on public bugs.
All the changes needed are submitted to the four components (build tools, MultidexTestRunner, AndroidJunitRunner and android gradle plugin) and we'll update this bug as soon as it is released, so it will be in Android Gradle Plugin 3.1.
Note that both the deprecated MultiDexTestRunner and the replacement AndroidJUnitRunner will support legacy multidex test APKs
All the changes needed are submitted to the four components (build tools, MultidexTestRunner, AndroidJunitRunner and android gradle plugin) and we'll update this bug as soon as it is released, so it will be in Android Gradle Plugin 3.1.
Note that both the deprecated MultiDexTestRunner and the replacement AndroidJUnitRunner will support legacy multidex test APKs
sz...@gmail.com <sz...@gmail.com> #64
Could you consider releasing the fix under 3.0.x (if that's even possible)?
Doing it in 3.1 will require everyone who wants to have multidex for test APK working to start using unstable version of AS and AGP.
Doing it in 3.1 will require everyone who wants to have multidex for test APK working to start using unstable version of AS and AGP.
zt...@gmail.com <zt...@gmail.com> #65
Please update documentation to reflect that legacy multidex IS supported, except broken by this bug (known issue) in AGP 3.0.
https://developer.android.com/studio/build/multidex.html#testing
> `Using multidex to create a test APK is not currently supported.`
> `Using multidex to create a test APK is not currently supported.`
cm...@google.com <cm...@google.com>
ga...@google.com <ga...@google.com> #66
This is fixed starting with 3.1.0-alpha04. Please try it out, and let us know if you are facing any issues. Thanks!
ja...@gmail.com <ja...@gmail.com> #67
Is it not "MultiDex.installInstrumentation(getContext(), getTargetContext());" in the AndroidJUnitRunner?
an...@gmail.com <an...@gmail.com> #68
3.1.0-alpha04 worked for me. Thanks for the fix.
le...@gmail.com <le...@gmail.com> #69
I just trying with 3.1.0-alpha06 and the problem seams to still be there =/
[Deleted User] <[Deleted User]> #70
This isn't working for me either with 3.1.0-alpha06. Can you clarify what was fixed, and what combination of Gradle, Android Gradle Plugin, Multidex library and Android Build Tools we should test against?
[Deleted User] <[Deleted User]> #71
Folks, any news in this issue? Could you explain how to make this work? Simply using AGP 3.1.0-alpha04 doesn't solve the problem
[Deleted User] <[Deleted User]> #72
Never mind. It does solve the problem
ga...@google.com <ga...@google.com> #73
Re #70:
You need to use Android plugin for Gradle 3.1.0-alpha04+, any compatible version of Gradle (e.g. 4.4) and BuildTools (e.g. 27.0.3). Multidex library 1.0.2 will be added by the plugin as a dependency automatically. With this, your build will be successful.
To run tests successfully, the test runner needs to support legacy test APK. AndroidJUnitRunner supports that, so you can use that.
You need to use Android plugin for Gradle 3.1.0-alpha04+, any compatible version of Gradle (e.g. 4.4) and BuildTools (e.g. 27.0.3). Multidex library 1.0.2 will be added by the plugin as a dependency automatically. With this, your build will be successful.
To run tests successfully, the test runner needs to support legacy test APK. AndroidJUnitRunner supports that, so you can use that.
ma...@gmail.com <ma...@gmail.com> #74
Looks much better but I still get an issue with multiDexKeepProguard file, it somehow feels it is not respected which classes should be added to the main dex file.
For example following your suggestion of tl;dr version the test crashes because some files are not found in the main dex file during the app start:
01-09 10:31:06.965 4861-4861/? W/dalvikvm: Class resolved by unexpected DEX: Ltimber/log/Timber$Tree;(0xa75def58):0x99f02000 ref [Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension;] Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension;(0xa75def58):0x99caf000
01-09 10:31:06.965 4861-4861/? W/dalvikvm: (Ltimber/log/Timber$Tree; had used a different Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension; during pre-verification)
01-09 10:31:06.965 4861-4861/? D/AndroidRuntime: Shutting down VM
01-09 10:31:06.965 4861-4861/? W/dalvikvm: threadid=1: thread exiting with uncaught exception (group=0xa66de228)
01-09 10:31:06.975 4861-4861/? E/InstrumentationResultPrinter: Failed to mark test No Tests as finished after process crash
01-09 10:31:06.975 4861-4861/? E/MonitoringInstr: Exception encountered by: Thread[main,5,main]. Dumping thread state to outputs and pining for the fjords.
java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
at timber.log.Timber$Tree.getStackTraceString(Timber.java:569)
at timber.log.Timber$Tree.prepareLog(Timber.java:544)
at timber.log.Timber$Tree.i(Timber.java:452)
at timber.log.Timber$1.i(Timber.java:288)
at timber.log.Timber.i(Timber.java:63)
Do you have any idea where does this pops out from?
For example following your suggestion of tl;dr version the test crashes because some files are not found in the main dex file during the app start:
01-09 10:31:06.965 4861-4861/? W/dalvikvm: Class resolved by unexpected DEX: Ltimber/log/Timber$Tree;(0xa75def58):0x99f02000 ref [Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension;] Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension;(0xa75def58):0x99caf000
01-09 10:31:06.965 4861-4861/? W/dalvikvm: (Ltimber/log/Timber$Tree; had used a different Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension; during pre-verification)
01-09 10:31:06.965 4861-4861/? D/AndroidRuntime: Shutting down VM
01-09 10:31:06.965 4861-4861/? W/dalvikvm: threadid=1: thread exiting with uncaught exception (group=0xa66de228)
01-09 10:31:06.975 4861-4861/? E/InstrumentationResultPrinter: Failed to mark test No Tests as finished after process crash
01-09 10:31:06.975 4861-4861/? E/MonitoringInstr: Exception encountered by: Thread[main,5,main]. Dumping thread state to outputs and pining for the fjords.
java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
at timber.log.Timber$Tree.getStackTraceString(Timber.java:569)
at timber.log.Timber$Tree.prepareLog(Timber.java:544)
at timber.log.Timber$Tree.i(Timber.java:452)
at timber.log.Timber$1.i(Timber.java:288)
at timber.log.Timber.i(Timber.java:63)
Do you have any idea where does this pops out from?
ga...@google.com <ga...@google.com> #75
Re #74:
This seems to be Java 8 specific bug, and I've filledhttps://issuetracker.google.com/71737186 to track this. Can we please continue discussion there?
This seems to be Java 8 specific bug, and I've filled
st...@gmail.com <st...@gmail.com> #76
We would love to use this fix, but we need a stable version of the gradle android plugin. When will Gradle Android Plugin 3.1.0 be released ?
fu...@gmail.com <fu...@gmail.com> #77
"Please " help me i want update oreo 8.0 without computer
[Deleted User] <[Deleted User]> #78
The release note for 3.1.0 doesn't mention this issue, is it fixed ?
[Deleted User] <[Deleted User]> #79
We are trying it and it looks like it's not working (though it used to be working in alpha04)
[Deleted User] <[Deleted User]> #80
There is a bug of a new kind in 3.1 + related to instrumented APKs & multidex
Until recently we had a big module, with all our code + all our instrurmentation tests code. Then we could check and the plugin (3.1.alpha and 3.1) work well to enable multidex in tests apks.
But we recently dissociated this big module: one contains the production code, the other one contains the instrumentation code. And then, the new plugin breaks: we can still a multidex production app, but the instrumentation test apk is not generated. We hit the 65K limit and the build reports this as an issue. Also, the android test don't have a task: transformClassesWithMultidexlistFor<variant>AndroidTest
What can go wrong ?
Until recently we had a big module, with all our code + all our instrurmentation tests code. Then we could check and the plugin (3.1.alpha and 3.1) work well to enable multidex in tests apks.
But we recently dissociated this big module: one contains the production code, the other one contains the instrumentation code. And then, the new plugin breaks: we can still a multidex production app, but the instrumentation test apk is not generated. We hit the 65K limit and the build reports this as an issue. Also, the android test don't have a task: transformClassesWithMultidexlistFor<variant>AndroidTest
What can go wrong ?
[Deleted User] <[Deleted User]> #81
To be more precise: we have one module named module_apk that contains:
* a few classes in production code
* quite a lot of classes of instrumentation tests
The module_apk wires together all other modules that are all library modules.
When adding multidexEnabled to module_apk, the production apk is multidexed, but not the test apk. There is no transform / task for the AndroidTest variant related to multidex.
When adding multidexEnabled to all default configuration of all modules, all of them have both instrumentation and production multidex tasks & transformations, all except module_apk...
We have no idea what is going wrong.
* a few classes in production code
* quite a lot of classes of instrumentation tests
The module_apk wires together all other modules that are all library modules.
When adding multidexEnabled to module_apk, the production apk is multidexed, but not the test apk. There is no transform / task for the AndroidTest variant related to multidex.
When adding multidexEnabled to all default configuration of all modules, all of them have both instrumentation and production multidex tasks & transformations, all except module_apk...
We have no idea what is going wrong.
ga...@google.com <ga...@google.com> #82
Re #81:
I've filledhttps://issuetracker.google.com/77183226 , let's please continue discussion there. Thanks.
I've filled
[Deleted User] <[Deleted User]> #83
What went wrong:
Execution failed for task ':app:transformClassesWithMultidexlistForLive'.
> com.android.build.api.transform.TransformException: Error while generating the main dex list.
Execution failed for task ':app:transformClassesWithMultidexlistForLive'.
> com.android.build.api.transform.TransformException: Error while generating the main dex list.
ga...@google.com <ga...@google.com> #84
Re #83: Please file a new issue, as that is error indicates there is a main dex list task error for the application, not for the test.
pe...@layer.com.c-02odbdyf.appstempdomain.goog <pe...@layer.com.c-02odbdyf.appstempdomain.goog> #85
Echoing #78. Our instrumented tests using multidex worked using the 3.0.0 version of the Android Plugin for gradle. Updated to 3.1.1 and it would just say empty test suite. I found this bug then reverted back to 3.1.0-alpha04 and the tests work again. Should this be working in 3.1.1?
pa...@gmail.com <pa...@gmail.com> #86
We (whoever has a repro) should probably file a new issue against 3.1.1 referencing this issue. This has been "marked as Fixed" 3 times... so it's possible the current problems are far from the original.
ga...@google.com <ga...@google.com> #87
Re #85, #86:
Yes, please file a new bug, and paste the link here. Issue in #78 was due to a custom plugin which would disable multidex. Thanks!
Yes, please file a new bug, and paste the link here. Issue in #78 was due to a custom plugin which would disable multidex. Thanks!
Description
Build #AI-171.3870562, built on April 1, 2017
JRE: 1.8.0_112-release-b736 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
gradle-3.4.1
classpath 'com.android.tools.build:gradle:2.4.0-alpha4'
buildTools : '25.0.1',
compileSdk : 25,
javaVersion: JavaVersion.VERSION_1_8,
minSdk : 16,
targetSdk : 25
Multidex is setup and works fine (compile, assemble and espresso test) with:
classpath 'com.android.tools.build:gradle:2.3.0'
When we bump up to 2.4 alpha 4 we get multidex issue when we try to run the tests:
(I repeat multidex is setup properly and everything works fine on plugin 2.3.0)
This is a scaffold-like very close to our project setup that I created to reproduce various gradle issues we encounter with our enteprise project:
(sadly I did not update it and maintain it in some time I can refresh it if you really need it or feel free to fork or PR)
This is the stacktrace of the issue
This is the command I ran on our project (should be the same on example project I attached)
./gradlew clean connectedNonpayUnitedStatesBleedingDebugAndroidTest --stacktrace
but I repeat I do not know yet does that project compiles even with the new plugin I can update it later on if you need it.