Status Update
No update yet.
Comments
su...@google.com
What steps are needed to reproduce this issue? Frequency of occurrence?
Which Android build are you using? (e.g. OPP1.170223.012)
Which device did you use to reproduce this issue?
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the bug report and screenshot to google drive and share the folder to android-bugreport@google.com, then share the link here.
ct...@google.com
Android version: T
Problem recurrence: Execute Antutu, and pay attention to the XML processing score
Phenomenon: replace the "name expected" in the KXmlParser.java file on the ssi side with a variable. After modification, the XML processing score of Angora Rabbit improved significantly.
Modify to: static final private String NAME_ EXPECTED = "name expected"; And use NAME_ EXPECTED for subsequent "name expected"
Thanks!
su...@google.com
bugreport has upload. Thankds!
ma...@gmail.com
We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
ct...@google.com
Okay, thanks!
su...@google.com
su...@google.com
Can you tell us if you have the link to the benchmark tests and the scores BEFORE and AFTER applying this change?
ma...@gmail.com
About 45000 before modification
About 49000 after modification
Thanks!
su...@google.com
Thanks for the above information, we have shared this with our product and engineering team and will update this issue with more information as it becomes available.
ma...@gmail.com
Thanks again for the feedback! Our product and engineering teams have evaluated the request and responded:
However, I can't find the source codes of the Antutu benchmarks.
Here are my suggestions, and you can consider one of the following options:
-
Can you provide the source code of benchmark to reproduce the result? Particularly, why do you mention that it improves the performance of JSON parsing? It would be great that we can reproduce the result and runs the benchmark continuously if the benchmark result is important
-
If you know how to change the code, you can consider uploading a patch to AOSP directly at
http://r.android.com/ . We will review it and consider accepting it.
yo...@gmail.com
Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.
Description
Version used: android.arch.work:work-runtime:1.0.0-alpha03
Devices/Android versions reproduced on: any
Stacktrace:
Caused by: java.lang.NullPointerException:
at androidx.work.impl.background.systemjob.SystemJobService.onCreate (SystemJobService.java:52)
at android.app.ActivityThread.handleCreateService (ActivityThread.java:3267)
at android.app.ActivityThread.-wrap5 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1641)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:163)
at android.app.ActivityThread.main (ActivityThread.java:6379)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:904)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:794)
Description:
Hi,
Yes, I know its a duplicate of
We released first version of our app with WorkManager with alpha02 library and without any explicit calls to WorkManager.initialize(...) and received a lot of NPEs in our tracker for all the places with WorkManager.getInstance() calls in our code and internally in the library. We don't have multiple processes so I was sure you default initialization with empty ContentProvider should work. But looks like its not always working! (maybe it is not always working on devices based on modified Android forks?) I can't reproduce it manually, but I have a lot of submitted crashes.
Well, we added WorkManager.initialize(this, new Configuration.Builder().build()); inside our Application.onCreate() before calling super.onCreate(); and it indeed helped. We had no such exceptions on the next release.
But for the next release after it we updated library version to alpha03 and it started crashing a lot again. Even as we still have WorkManager.initialize(...) inside Application.onCreate(). Guys, issues like this are making adapting your library into real applications quite complicated, please consider reworking of the library initialization to make it more predictable.
I see that mostly it is crashing on Xiaomi devices, attaching screenshot with devices list.