Fixed
Status Update
No update yet.
Comments
ag...@google.com
Thanks for the report Tolriq! Would it be possible for you to upload the APK built with D8 for which this fails? Is it possible to create a small reproduction project so that it is easier for us to reproduce?
to...@gmail.com
I've attached the bugged APK.
The application is very large and complex I'll try to create a repro app but as it can take a long time, would appreciate if you can confirm that you need it :)
And not fully related but tied to build tools I've reportedhttps://issuetracker.google.com/issues/73534863 that does not seems to be triaged. Maybe I chose a wrong section don't know if you can help to have it seen. As both aapt2 and D8 will become mandatory and both have problem with my app :(
And a thank you to the D8 team, build process with desugaring is quite faster for me :)
The application is very large and complex I'll try to create a repro app but as it can take a long time, would appreciate if you can confirm that you need it :)
And not fully related but tied to build tools I've reported
And a thank you to the D8 team, build process with desugaring is quite faster for me :)
ag...@google.com
Thank you Tolriq! I'll have a look. Just to make sure I'm looking at the right thing: can you show me the D8 related parts of your gradle.properties when the app works and when the app doesn't work? I would like to figure out if this is related to D8 desugaring or D8 dexing.
to...@gmail.com
Gradle.properties that works.
org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configureondemand=true
org.gradle.jvmargs=-Xmx4G
#-XX:MaxPermSize=4G -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
#Android
android.enableAapt2=false
android.enableBuildCache=true
android.enableD8.desugaring=false
android.enableD8=false
I only tested both D8 and D8.desugaring to true and then it crash. Will try in a few minutes with only D8 true and D8.desugar to false. (But a release build is 8 minutes compilation on a i6850K 64G Ram on an Samsung M2 960 Pro ;)
That part of the code looks like:
JobManager.queueTask(() -> {
if (Device.hasOreoApi()) {
try {
NotificationManager notificationManager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
if (notificationManager != null) {
List<NotificationChannel> channels = notificationManager.getNotificationChannels();
Both JobManager and Device are Kotlin objects but the Application is still Java.
org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configureondemand=true
org.gradle.jvmargs=-Xmx4G
#-XX:MaxPermSize=4G -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
#Android
android.enableAapt2=false
android.enableBuildCache=true
android.enableD8.desugaring=false
android.enableD8=false
I only tested both D8 and D8.desugaring to true and then it crash. Will try in a few minutes with only D8 true and D8.desugar to false. (But a release build is 8 minutes compilation on a i6850K 64G Ram on an Samsung M2 960 Pro ;)
That part of the code looks like:
JobManager.queueTask(() -> {
if (Device.hasOreoApi()) {
try {
NotificationManager notificationManager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
if (notificationManager != null) {
List<NotificationChannel> channels = notificationManager.getNotificationChannels();
Both JobManager and Device are Kotlin objects but the Application is still Java.
to...@gmail.com
Ok so tested without D8 desugar and fails too.
The error message is a little different:
Process: org.leetzone.android.yatsewidgetfree, PID: 4943
java.lang.VerifyError: Verifier rejected class org.leetzone.android.yatsewidget.b due to bad method void org.leetzone.android.yatsewidget.b.run() (declaration of 'org.leetzone.android.yatsewidget.b' appears in /data/app/org.leetzone.android.yatsewidgetfree-1/base.apk)
at org.leetzone.android.yatsewidget.YatseApplication.onCreate(YatseApplication.java:383)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1011)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4518)
at android.app.ActivityThread.access$1500(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1339)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5221)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
The b method is the lambda passed to JobManager.queueTask
The error message is a little different:
Process: org.leetzone.android.yatsewidgetfree, PID: 4943
java.lang.VerifyError: Verifier rejected class org.leetzone.android.yatsewidget.b due to bad method void org.leetzone.android.yatsewidget.b.run() (declaration of 'org.leetzone.android.yatsewidget.b' appears in /data/app/org.leetzone.android.yatsewidgetfree-1/base.apk)
at org.leetzone.android.yatsewidget.YatseApplication.onCreate(YatseApplication.java:383)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1011)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4518)
at android.app.ActivityThread.access$1500(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1339)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5221)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
The b method is the lambda passed to JobManager.queueTask
ag...@google.com
Thanks for being some responsive Tolriq, this is a huge help in debugging this. Can you upload the APK that works as well, then I can compare the code that works to the code that doesn't. Maybe that will give me an indication of what is going wrong here.
to...@gmail.com
I'll do in 2 post to not mix the files.
Here's the apk built with D8 true and D8.desugaring false
The one that works is still compiling, should only have some updated translations and build number as I'll push it to beta track too :)
You should compare this one bugged with the next one unbugged as there's other code changes since the 1st uploaded APK.
Here's the apk built with D8 true and D8.desugaring false
The one that works is still compiling, should only have some updated translations and build number as I'll push it to beta track too :)
You should compare this one bugged with the next one unbugged as there's other code changes since the 1st uploaded APK.
to...@gmail.com
And here's the APK that does work.
ag...@google.com
Thank you!
to...@gmail.com
Hum I've just seen that the previous build is not a beta build, should not impact at all the code that interest you, but this change a BuildConfig so there's much more code change between the 2 than I thought. Hope it's not a problem.
If it is I can trigger a broken beta build to compare.
If it is I can trigger a broken beta build to compare.
ag...@google.com
That is not a problem Tolriq. I think I see what the problem is: it looks like the verifier on these versions of Android is broken and assumes that the register for the receiver is never overwritten. That is unfortunate, but if I can verify that this is the issue I can create a workaround.
to...@gmail.com
Ok can test anything as I long as you can provide windows compiled things :)
ag...@google.com
Great, thank you! I'll update this bug when I have a potential workaround ready for testing. :)
ag...@google.com
Tolriq, I have a workaround that I think will fix this. It would be great if you could double-check on your app. I have attached a d8.jar archive. In order to use this version, go to the project build.gradle file and add this d8.jar to the classpath BEFORE the gradle plugin:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath files('/usr/local/google/home/ager/ssd/r8/build/libs/d8.jar') // UPDATE TO POINT TO YOUR d8.jar
classpath 'com.android.tools.build:gradle:3.1.0-beta3'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath files('/usr/local/google/home/ager/ssd/r8/build/libs/d8.jar') // UPDATE TO POINT TO YOUR d8.jar
classpath 'com.android.tools.build:gradle:3.1.0-beta3'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
ag...@google.com
This d8.jar has been modified so that if you watch the text version of the build output you should see "Using: v1.1.7-dev" in the output if the setup has correctly picked up this version of D8.
to...@gmail.com
It worked on Android 4 and 5 and quickly tested on Android 7.1 still works :) (See generated APK)
Build time was 8m 46s when I remembered it was faster previously when using D8. Maybe there's something else on the computer but worth noticing in case it's a side effect of your changes.
Don't know if your team only works on D8 or whole gradle build time but I'm a great example of slow build times that would love some more improvement :)
Do you have an ETA for this yo go public ? (Just to know if I should include a build with it in this beta cycle or wait for when it's ready).
Build time was 8m 46s when I remembered it was faster previously when using D8. Maybe there's something else on the computer but worth noticing in case it's a side effect of your changes.
Don't know if your team only works on D8 or whole gradle build time but I'm a great example of slow build times that would love some more improvement :)
Do you have an ETA for this yo go public ? (Just to know if I should include a build with it in this beta cycle or wait for when it's ready).
to...@gmail.com
Another note:
Resulting classes.dex without D8: 9970 classes with 50350 methods and references 62758 methods
With D8: 9954 classe with 51489 methods and references 63724 methods
That's nearly 1000 more references for the same code, not small number :( (Fun part is that size is smaller despite this increase).
Resulting classes.dex without D8: 9970 classes with 50350 methods and references 62758 methods
With D8: 9954 classe with 51489 methods and references 63724 methods
That's nearly 1000 more references for the same code, not small number :( (Fun part is that size is smaller despite this increase).
ag...@google.com
Thanks for testing! I'll get this patch in shape for landing tomorrow. Then it will be a couple of weeks before the fix ends up in Android Studio. :-\
Regarding the method references: I'm guessing this is because of D8-based desugaring? D8 itself shouldn't change the amount of method references, but maybe there are things that we can do in the desugaring part to limit the amount of methods and method references we end up generating.
Thanks again both for reporting this issue and for being so responsive in helping us fix it!
Regarding the method references: I'm guessing this is because of D8-based desugaring? D8 itself shouldn't change the amount of method references, but maybe there are things that we can do in the desugaring part to limit the amount of methods and method references we end up generating.
Thanks again both for reporting this issue and for being so responsive in helping us fix it!
to...@gmail.com
Ok so without D8 desugar got the same result as without D8 like you said. Let's hope you can reduce that amount as 63,7K is dangerously approaching the limit.
Couple of week like possible it's not in 3.1 final ? It's been a very long journey to get to 99,99% crash free sessions (remaining are Support Lib or Play Services :( ) so to keep it that way it's better if I use consistent build tools even for my debug builds and should probably also disable D8 for them.
Thanks to you to fix that so quickly let's hope someone does the same for aapt2 issue.
Couple of week like possible it's not in 3.1 final ? It's been a very long journey to get to 99,99% crash free sessions (remaining are Support Lib or Play Services :( ) so to keep it that way it's better if I use consistent build tools even for my debug builds and should probably also disable D8 for them.
Thanks to you to fix that so quickly let's hope someone does the same for aapt2 issue.
ag...@google.com
We will definitely get this fix into 3.1 final. :)
to...@gmail.com
Ok thanks 3.1 is OK for me so I'll keep D8 for my debug build to spot other issues then.
ap...@google.com
Project: r8
Branch: master
commit 02767ca1118d0c3a1c285576e2e224eedc496241
Author: Mads Ager <ager@google.com>
Date: Tue Feb 27 10:23:14 2018
Block the receiver register always before Android M.
Art before M assumes that the type of the value in the receiver
register never changes. This assumption is used during verification
and therefore allowing reused of the receiver register can make
verification fail on these devices.
R=sgjesse@google.com, zerny@google.com
Bug: 73787793
Change-Id: Icfe9cd87be16d8e8364c319876c0700a3285d5fa
M src/main/java/com/android/tools/r8/ir/regalloc/LinearScanRegisterAllocator.java
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
https://r8-review.googlesource.com/17201
Branch: master
commit 02767ca1118d0c3a1c285576e2e224eedc496241
Author: Mads Ager <ager@google.com>
Date: Tue Feb 27 10:23:14 2018
Block the receiver register always before Android M.
Art before M assumes that the type of the value in the receiver
register never changes. This assumption is used during verification
and therefore allowing reused of the receiver register can make
verification fail on these devices.
R=sgjesse@google.com, zerny@google.com
Bug: 73787793
Change-Id: Icfe9cd87be16d8e8364c319876c0700a3285d5fa
M src/main/java/com/android/tools/r8/ir/regalloc/LinearScanRegisterAllocator.java
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
ag...@google.com
Fix has been merged into studio-3.1 branch but will most likely not make the RC1 build. We should get this into 3.1 stable though.
ag...@google.com
to...@gmail.com
Sorry to bother you but I've found a new issue in AGP 3.1 rc1 https://issuetracker.google.com/issues/74227566 and when reporting in what I think the correct category it's not auto assigned for triage so will probably be ignored as often when it's the case.
Don't know if you can assign someone :( Would be really cool to have some sorting the issue categories so users can know which are actively followed and those who are not :(
Don't know if you can assign someone :( Would be really cool to have some sorting the issue categories so users can know which are actively followed and those who are not :(
ag...@google.com
Hi Tolriq, no worries, when bugs are filed they are typically unassigned. All unassigned bugs are then triaged and assigned an owner. The gradle team will definitely pick this one up. :)
to...@gmail.com
From experience this is really really not always the case ;) the aapt2 was not seen before you assigned someone :) And I still have issues without any reaction since 2015 and 2016 ;)
Things are improving but most of the time we still need to tag someone to have things looked at for sure.
Anyway thanks again.
Things are improving but most of the time we still need to tag someone to have things looked at for sure.
Anyway thanks again.
to...@gmail.com
Can you confirm the fix is in RC2? It's not listed in the bug fixed but seems to works. Would be a perfect timing for my new beta cycle starting today :)
ag...@google.com
The fix is in RC2, you should be good to go. :) Please do let us know if you are still seeing issues. :)
to...@gmail.com
Thanks will push to a 6K users beta group today if there's other issues I guess I'll now fast :)
to...@gmail.com
Ok so the app is now in prod and I see a new crash on Android 4.4.2 from crashlytics on Acer / Lenovo and TCL so does not seems to be device related. Not yet able to reproduce but reporting before Week End as we are different Time Zones :)
Since this error is on something that I did not change and is an assertion error I guess it might also be tied to D8 or D8 desugar.
It's from well known square libraries. Will try to see if I can get more details. (Last version of Okio sohttps://github.com/square/okio/blob/master/okio/src/main/java/okio/AsyncTimeout.java#L101 )
Unchanged code from my previous version, only diff is D8.
Fatal Exception: java.lang.AssertionError
at okio.AsyncTimeout.scheduleTimeout(AsyncTimeout.java:101)
at okio.AsyncTimeout.enter(AsyncTimeout.java:80)
at okio.AsyncTimeout$2.read(AsyncTimeout.java:235)
at okio.RealBufferedSource.read(RealBufferedSource.java:47)
at okhttp3.internal.http1.Http1Codec$AbstractSource.read(Http1Codec.java:363)
at okhttp3.internal.http1.Http1Codec$FixedLengthSource.read(Http1Codec.java:407)
at okio.RealBufferedSource.request(RealBufferedSource.java:68)
at com.squareup.moshi.JsonUtf8Reader.nextNonWhitespace(JsonUtf8Reader.java:955)
at com.squareup.moshi.JsonUtf8Reader.doPeek(JsonUtf8Reader.java:298)
at com.squareup.moshi.JsonUtf8Reader.nextLong(JsonUtf8Reader.java:733)
at com.squareup.moshi.StandardJsonAdapters$8.fromJson(StandardJsonAdapters.java:2176)
at com.squareup.moshi.ClassJsonAdapter.com.squareup.moshi.ClassJsonAdapter$FieldBinding.read(ClassJsonAdapter.java:1205)
at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:76)
at com.squareup.moshi.CollectionJsonAdapter$2.toJson(CollectionJsonAdapter.java:53)
at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
at com.squareup.moshi.ClassJsonAdapter.com.squareup.moshi.ClassJsonAdapter$FieldBinding.read(ClassJsonAdapter.java:1205)
at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
at com.squareup.moshi.ClassJsonAdapter.com.squareup.moshi.ClassJsonAdapter$FieldBinding.read(ClassJsonAdapter.java:1205)
at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
at com.squareup.moshi.JsonAdapter.fromJson(JsonAdapter.java:35)
Don't have APK right now but app is athttps://play.google.com/store/apps/details?id=org.leetzone.android.yatsewidgetfree
If you have any idea of things to test / provides just tell me so I can prepare all for Monday.
Since this error is on something that I did not change and is an assertion error I guess it might also be tied to D8 or D8 desugar.
It's from well known square libraries. Will try to see if I can get more details. (Last version of Okio so
Unchanged code from my previous version, only diff is D8.
Fatal Exception: java.lang.AssertionError
at okio.AsyncTimeout.scheduleTimeout(AsyncTimeout.java:101)
at okio.AsyncTimeout.enter(AsyncTimeout.java:80)
at okio.AsyncTimeout$2.read(AsyncTimeout.java:235)
at okio.RealBufferedSource.read(RealBufferedSource.java:47)
at okhttp3.internal.http1.Http1Codec$AbstractSource.read(Http1Codec.java:363)
at okhttp3.internal.http1.Http1Codec$FixedLengthSource.read(Http1Codec.java:407)
at okio.RealBufferedSource.request(RealBufferedSource.java:68)
at com.squareup.moshi.JsonUtf8Reader.nextNonWhitespace(JsonUtf8Reader.java:955)
at com.squareup.moshi.JsonUtf8Reader.doPeek(JsonUtf8Reader.java:298)
at com.squareup.moshi.JsonUtf8Reader.nextLong(JsonUtf8Reader.java:733)
at com.squareup.moshi.StandardJsonAdapters$8.fromJson(StandardJsonAdapters.java:2176)
at com.squareup.moshi.ClassJsonAdapter.com.squareup.moshi.ClassJsonAdapter$FieldBinding.read(ClassJsonAdapter.java:1205)
at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:76)
at com.squareup.moshi.CollectionJsonAdapter$2.toJson(CollectionJsonAdapter.java:53)
at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
at com.squareup.moshi.ClassJsonAdapter.com.squareup.moshi.ClassJsonAdapter$FieldBinding.read(ClassJsonAdapter.java:1205)
at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
at com.squareup.moshi.ClassJsonAdapter.com.squareup.moshi.ClassJsonAdapter$FieldBinding.read(ClassJsonAdapter.java:1205)
at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
at com.squareup.moshi.JsonAdapter.fromJson(JsonAdapter.java:35)
Don't have APK right now but app is at
If you have any idea of things to test / provides just tell me so I can prepare all for Monday.
ag...@google.com
Hi Tolriq, unfortunately these MediaTek based 4.4.x devices had another bug that we just implemented a workaround for: https://b.corp.google.com/issues/75408029 :-(
The fix will be in the next version of android studio 3.1 and will make it into 3.2 over the next couple of weeks as well. I managed to reproduce this same stack trace that you report on one of my devices before the latest fix. Cannot reproduce it after the latest fix.
Sorry for the inconvenience. I hope you'll give D8 another shot when the next 3.1 release is out. :)
The fix will be in the next version of android studio 3.1 and will make it into 3.2 over the next couple of weeks as well. I managed to reproduce this same stack trace that you report on one of my devices before the latest fix. Cannot reproduce it after the latest fix.
Sorry for the inconvenience. I hope you'll give D8 another shot when the next 3.1 release is out. :)
ag...@google.com
In case you want to test it out now, you can also take the attached d8.jar and make android studio use it by changing your build.gradle file to something like:
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath files('/usr/local/google/home/ager/ssd/r8/build/libs/d8.jar') // UPDATE TO POINT TO YOUR d8.jar
classpath 'com.android.tools.build:gradle:3.1.0-beta3'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath files('/usr/local/google/home/ager/ssd/r8/build/libs/d8.jar') // UPDATE TO POINT TO YOUR d8.jar
classpath 'com.android.tools.build:gradle:3.1.0-beta3'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
ag...@google.com
In order to test that your apk has been compiled with the right version you can do:
java -cp build/libs/d8.jar com.android.tools.r8.ExtractMarker app-release.apk
It should include the version number 1.0.20 in the marker if the new jar is used.
java -cp build/libs/d8.jar com.android.tools.r8.ExtractMarker app-release.apk
It should include the version number 1.0.20 in the marker if the new jar is used.
to...@gmail.com
Thanks for the answer. Unfortunately since the bug was not spotted in the 6K beta testers I guess none of them have those devices so will be hard to test. Will wait for next release to push a fix in prod. As none of those users have contacted me yet.
And just got another crash on Android 4.2.2 thl t11 device.
Fatal Exception: java.lang.IllegalArgumentException: Priority out of range: 12
at java.lang.Thread.setPriority(Thread.java:951)
at com.genimee.android.utils.threads.ScalingThreadPoolExecutor.beforeExecute(ScalingThreadPoolExecutor.kt:27)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1077)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
at java.lang.Thread.run(Thread.java:838)
The thing is that I normally never use 12 as priority and the related code is (kotlin 1.2.30) :
override fun beforeExecute(thread: Thread, runnable: Runnable?) {
try {
thread.priority = defaultThreadPriority
} catch (ignore: Exception) {
}
activeCount.incrementAndGet()
}
So there's no way such exception should pass the try catch, so probably another D8 issue :(
If this the same kind of issue that your fix fix?
And just got another crash on Android 4.2.2 thl t11 device.
Fatal Exception: java.lang.IllegalArgumentException: Priority out of range: 12
at java.lang.Thread.setPriority(Thread.java:951)
at com.genimee.android.utils.threads.ScalingThreadPoolExecutor.beforeExecute(ScalingThreadPoolExecutor.kt:27)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1077)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
at java.lang.Thread.run(Thread.java:838)
The thing is that I normally never use 12 as priority and the related code is (kotlin 1.2.30) :
override fun beforeExecute(thread: Thread, runnable: Runnable?) {
try {
thread.priority = defaultThreadPriority
} catch (ignore: Exception) {
}
activeCount.incrementAndGet()
}
So there's no way such exception should pass the try catch, so probably another D8 issue :(
If this the same kind of issue that your fix fix?
to...@gmail.com
Users starts to wakeup and use the app more :(
On those same devices start to see a lot of:
Caused by java.lang.ClassCastException: android.support.graphics.drawable.VectorDrawableCompat cannot be cast to android.graphics.drawable.LayerDrawable
at android.support.v7.widget.AppCompatDrawableManager.tintDrawable(AppCompatDrawableManager.java:275)
at android.support.v7.widget.AppCompatDrawableManager.getDrawable(AppCompatDrawableManager.java:203)
at android.support.v7.widget.TintTypedArray.getDrawableIfKnown(TintTypedArray.java:85)
at android.support.v7.widget.AppCompatProgressBarHelper.loadFromAttributes(AppCompatProgressBarHelper.java:54)
at android.support.v7.widget.AppCompatSeekBarHelper.loadFromAttributes(AppCompatSeekBarHelper.java:48)
at android.support.v7.widget.AppCompatSeekBar.(AppCompatSeekBar.java:50)
at android.support.v7.widget.AppCompatSeekBar.(AppCompatSeekBar.java:43)
at java.lang.reflect.Constructor.constructNative(Constructor.java)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at android.view.LayoutInflater.createView(LayoutInflater.java:594)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:696)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:755)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:758)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:758)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:758)
at android.view.LayoutInflater.inflate(LayoutInflater.java:492)
at android.view.LayoutInflater.inflate(LayoutInflater.java:397)
I suppose that you are no more around since it's the Week End but I'm not sure to understand if the mentioned fix could fix those crashes too.
Since I'm way off my 99,99% crash free session baseline in prod, if you can't confirm it might fix those 2, I'll push a no D8 build to prod soon.
On those same devices start to see a lot of:
Caused by java.lang.ClassCastException: android.support.graphics.drawable.VectorDrawableCompat cannot be cast to android.graphics.drawable.LayerDrawable
at android.support.v7.widget.AppCompatDrawableManager.tintDrawable(AppCompatDrawableManager.java:275)
at android.support.v7.widget.AppCompatDrawableManager.getDrawable(AppCompatDrawableManager.java:203)
at android.support.v7.widget.TintTypedArray.getDrawableIfKnown(TintTypedArray.java:85)
at android.support.v7.widget.AppCompatProgressBarHelper.loadFromAttributes(AppCompatProgressBarHelper.java:54)
at android.support.v7.widget.AppCompatSeekBarHelper.loadFromAttributes(AppCompatSeekBarHelper.java:48)
at android.support.v7.widget.AppCompatSeekBar.(AppCompatSeekBar.java:50)
at android.support.v7.widget.AppCompatSeekBar.(AppCompatSeekBar.java:43)
at java.lang.reflect.Constructor.constructNative(Constructor.java)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at android.view.LayoutInflater.createView(LayoutInflater.java:594)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:696)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:755)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:758)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:758)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:758)
at android.view.LayoutInflater.inflate(LayoutInflater.java:492)
at android.view.LayoutInflater.inflate(LayoutInflater.java:397)
I suppose that you are no more around since it's the Week End but I'm not sure to understand if the mentioned fix could fix those crashes too.
Since I'm way off my 99,99% crash free session baseline in prod, if you can't confirm it might fix those 2, I'll push a no D8 build to prod soon.
ag...@google.com
The bug in these VMs that we just landed a workaround for is around long comparisons. Therefore, any code that operates on longs and compares them can give wrong results. Once long arithmetic and comparisons produce wrong results there are many ways the app can go wrong. Since I don't have reproductions for those stack traces I cannot guarantee that it is the same issue. However, without the workaround things can go wrong in many different ways, so I wouldn't be surprised if it was the same issue.
to...@gmail.com
Ok thanks I'll give the fix a direct shot in prod as in all cases those would need to be fixed at some point so having info will be useful. Something that I really hate to do :(
Let's hope it does not break more things.
I suppose there's no way to reproduce with emulators as I do not own one of those devices ?
Let's hope it does not break more things.
I suppose there's no way to reproduce with emulators as I do not own one of those devices ?
to...@gmail.com
After waiting enough to be sure, all strange new crashes are fixed with the last D8. Thanks a lot for saving my week end :)
Totally unrelated but since you are the most efficient Googler I crossed until now do you have any way / right to give details abouthttps://issuetracker.google.com/issues/72581498 ( I can't see the +Blocked by: 72985953)
Totally unrelated but since you are the most efficient Googler I crossed until now do you have any way / right to give details about
to...@gmail.com
Actually I speak too soon :(
There's still one issue on those devices.
Fatal Exception: java.lang.IllegalArgumentException: Priority out of range: 12
at java.lang.Thread.setPriority(Thread.java:951)
at com.genimee.android.utils.threads.ScalingThreadPoolExecutor.beforeExecute(ScalingThreadPoolExecutor.kt:27)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1077)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
at java.lang.Thread.run(Thread.java:838)
With that code being
class ScalingThreadPoolExecutor : ThreadPoolExecutor {
......
override fun beforeExecute(thread: Thread, runnable: Runnable?) {
try {
thread.priority = defaultThreadPriority
} catch (ignore: Exception) {
}
activeCount.incrementAndGet()
}
}
I do not set 12 as priority and the catch Exception should catch that exception
There's still one issue on those devices.
Fatal Exception: java.lang.IllegalArgumentException: Priority out of range: 12
at java.lang.Thread.setPriority(Thread.java:951)
at com.genimee.android.utils.threads.ScalingThreadPoolExecutor.beforeExecute(ScalingThreadPoolExecutor.kt:27)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1077)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
at java.lang.Thread.run(Thread.java:838)
With that code being
class ScalingThreadPoolExecutor : ThreadPoolExecutor {
......
override fun beforeExecute(thread: Thread, runnable: Runnable?) {
try {
thread.priority = defaultThreadPriority
} catch (ignore: Exception) {
}
activeCount.incrementAndGet()
}
}
I do not set 12 as priority and the catch Exception should catch that exception
ag...@google.com
Sorry to hear that there are still issues Tolriq. Is this happening only on those same phones?
Also, how is defaultThreadPriority declared in the code above? Is it a final field that is never manipulated once set?
Also, how is defaultThreadPriority declared in the code above? Is it a final field that is never manipulated once set?
ag...@google.com
I unfortunately don't see any news about the VectorCompat issue. Is that also only happening on certain 4.4 phones? Is it also only happening when whipping with D8 or is that also happening with DX?
to...@gmail.com
It's a var but currently only set during object creation.
I attached the source code. Current prod is Kotlin 1.2.30
That code is then called via:
private val lowPriorityPoolExecutor = ScalingThreadPoolExecutor.newScalingThreadPool(1, 5, 30, "JM", 12)
I finally found the case where I create the pool with priority 12 (was actually 10+2 :p). So the 12 value is normal but the crash not being catched is not.
The pools are created nearly at application start so 99,99% of the time but the crash only occurred 10 times for 4 users, so does not seems to be constant as the previous issues did have wayyyyyyyyy bigger numbers showing a larger population for those devices.
The bug may just be around the catch with the crash being normal as crash being rare. (Reason while the catch is here is forgotten, I can try to find the commit where I added the catch, but since this part was renamed + migrated to kotlin + moved to submodule it might take a while).
For the vector compat it's not tied to D8 :( I was hoping D8 / aapt2 fix that as a side effect but it did not :( Still my main crash source.
This is a long lasting issue, but I know getting support without a repro case is nearly impossible so reported a little late :(
Would be really great if someone from the Support lib team watch it to at least add better log error so we can advance on this; Because without repro and with team not adding logs / debug tools. The issue can stay forever as no real way to contact people :(
As you can see I'm available to debug and work on issue ;) I've done the same job as with you for an ongoing Android Auto issue, but it tooks 2 months to reach the correct support first :(
I'm pretty sure there's a rare rare condition or something that prevent the vector to be loaded if too early before something is fully init, but it's added to the ignore list that will then try to load the vector by OS that obviously can't work. Crashing earlier would give the reason and avoid headache since in all case it will crash later just without any info.
I attached the source code. Current prod is Kotlin 1.2.30
That code is then called via:
private val lowPriorityPoolExecutor = ScalingThreadPoolExecutor.newScalingThreadPool(1, 5, 30, "JM", 12)
I finally found the case where I create the pool with priority 12 (was actually 10+2 :p). So the 12 value is normal but the crash not being catched is not.
The pools are created nearly at application start so 99,99% of the time but the crash only occurred 10 times for 4 users, so does not seems to be constant as the previous issues did have wayyyyyyyyy bigger numbers showing a larger population for those devices.
The bug may just be around the catch with the crash being normal as crash being rare. (Reason while the catch is here is forgotten, I can try to find the commit where I added the catch, but since this part was renamed + migrated to kotlin + moved to submodule it might take a while).
For the vector compat it's not tied to D8 :( I was hoping D8 / aapt2 fix that as a side effect but it did not :( Still my main crash source.
This is a long lasting issue, but I know getting support without a repro case is nearly impossible so reported a little late :(
Would be really great if someone from the Support lib team watch it to at least add better log error so we can advance on this; Because without repro and with team not adding logs / debug tools. The issue can stay forever as no real way to contact people :(
As you can see I'm available to debug and work on issue ;) I've done the same job as with you for an ongoing Android Auto issue, but it tooks 2 months to reach the correct support first :(
I'm pretty sure there's a rare rare condition or something that prevent the vector to be loaded if too early before something is fully init, but it's added to the ignore list that will then try to load the vector by OS that obviously can't work. Crashing earlier would give the reason and avoid headache since in all case it will crash later just without any info.
to...@gmail.com
Do you need anything else or more details?
I'm going to start a new beta cycle so will be able to test things if there's the need.
I'm going to start a new beta cycle so will be able to test things if there's the need.
ag...@google.com
I'm sorry for the slow replies on this. Was on vacation last week and this week has been hectic. Let me file a new bug report on the exception catching issue so that we have an open bug report for that issue which seems different than the original one here. I'll cc you on that bug so you get updates when we get the cycles to look into it. :)
to...@gmail.com
No need to apologize, you saved my Week-End earlier, you are my hero :p
to...@gmail.com
ag...@google.com why leaving https://issuetracker.google.com/issues/79164247 when I did report that issue right here too #36 just after the D8 switch.
I know how to use VectorCompat and the app does work on Android 4 ;) Except some devices some times.
As random and rare ashttps://issuetracker.google.com/issues/77672662 but appeared at the same time.
Answering here since you left the other one you won't get the answer.
I know how to use VectorCompat and the app does work on Android 4 ;) Except some devices some times.
As random and rare as
Answering here since you left the other one you won't get the answer.
ag...@google.com
Hi Tolriq,
thanks for the reply and sorry about dropping the mailing list from those issues. I was just marking them as not assigned (it was assigned to the mailing list which doesn't make sense). I accidentally removed the mailing list instead of moving it to cc. Fixed. :)
Cheers,
Mads
thanks for the reply and sorry about dropping the mailing list from those issues. I was just marking them as not assigned (it was assigned to the mailing list which doesn't make sense). I accidentally removed the mailing list instead of moving it to cc. Fixed. :)
Cheers,
Mads
[Deleted User] <[Deleted User]>
delete
ky...@gmail.com
fine
Description
Building a release version of my app generate wrong code that will trigger
02-23 09:10:18.064: I/art(17467): couldn't find method android.app.NotificationManager.getNotificationChannels ()Ljava/util/List;
02-23 09:10:18.064: I/art(17467): void org.leetzone.android.yatsewidget.YatseApplication.h() failed to verify: 'this' argument 'Reference: java.lang.Object' not instance of 'Reference: android.content.ContextWrapper'
The problem is that this code is correctly secured behind a call to Device.hasOreoApi().
The Device.hasOreoApi() is a simple SDK_INT check in a Kotlin object as JvmStatic in secondary module.
Just disabling d8 in gradle.properties generates a working APK.
Logcat from Google Pre Launch :
02-23 09:10:18.064: I/art(17467): Verification error in void org.leetzone.android.yatsewidget.YatseApplication.h()
02-23 09:10:18.064: I/art(17467): couldn't find method android.app.NotificationManager.getNotificationChannels ()Ljava/util/List;
02-23 09:10:18.064: I/art(17467): void org.leetzone.android.yatsewidget.YatseApplication.h() failed to verify: 'this' argument 'Reference: java.lang.Object' not instance of 'Reference: android.content.ContextWrapper'
02-23 09:10:18.094: E/art(17467): Verification failed on class org.leetzone.android.yatsewidget.YatseApplication in /data/app/org.leetzone.android.yatsewidgetfree-1/base.apk because: Verifier rejected class org.leetzone.android.yatsewidget.YatseApplication due to bad method void org.leetzone.android.yatsewidget.YatseApplication.h()
02-23 09:10:18.104: E/AndroidRuntime(17467): FATAL EXCEPTION: main
02-23 09:10:18.104: E/AndroidRuntime(17467): Process: org.leetzone.android.yatsewidgetfree, PID: 17467
02-23 09:10:18.104: E/AndroidRuntime(17467): java.lang.VerifyError: Verifier rejected class org.leetzone.android.yatsewidget.YatseApplication due to bad method void org.leetzone.android.yatsewidget.YatseApplication.h() (declaration of 'org.leetzone.android.yatsewidget.YatseApplication' appears in /data/app/org.leetzone.android.yatsewidgetfree-1/base.apk)
02-23 09:10:18.104: E/AndroidRuntime(17467): at java.lang.reflect.Constructor.newInstance(Native Method)
02-23 09:10:18.104: E/AndroidRuntime(17467): at java.lang.Class.newInstance(Class.java:1572)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.app.Instrumentation.newApplication(Instrumentation.java:995)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.app.Instrumentation.newApplication(Instrumentation.java:980)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.app.LoadedApk.makeApplication(LoadedApk.java:582)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4766)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.app.ActivityThread.access$1900(ActivityThread.java:152)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1402)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.os.Handler.dispatchMessage(Handler.java:102)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.os.Looper.loop(Looper.java:135)
02-23 09:10:18.104: E/AndroidRuntime(17467): at android.app.ActivityThread.main(ActivityThread.java:5538)
02-23 09:10:18.104: E/AndroidRuntime(17467): at java.lang.reflect.Method.invoke(Native Method)
02-23 09:10:18.104: E/AndroidRuntime(17467): at java.lang.reflect.Method.invoke(Method.java:372)
02-23 09:10:18.104: E/AndroidRuntime(17467): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:960)
02-23 09:10:18.104: E/AndroidRuntime(17467): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)