Status Update
Comments
dn...@google.com <dn...@google.com> #2
Ma...@htc.com <Ma...@htc.com> #3
Yes, I should have mentioned it.
And I'm using com.android.tools.build:gradle:2.0.0-beta6
And I'm using com.android.tools.build:gradle:2.0.0-beta6
dn...@google.com <dn...@google.com> #4
Hi,
Let me know if scaleType='fitXY' can be a workaround for you , in order to get the image look sharp.
The marshmallow Vs Lollipop is due to a special scaling treatment added into marshmallow.
Also, for your comments:
"
Correct behavior:
The vector drawable should scale without quality loss. So if we want to use the same asset in 3 different sizes in our application, we don't have to duplicate vector_drawable.xml 3 times with different hardcoded sizes.
"
Even though I totally agree this should be the case, in reality, the Android platform has performance concern such that we have not reach the ideal world yet.
So it is actually recommended to use 3 different vector_drawable.xml for better performance if you are sure you want to draw 3 different size on the screen at the same time.
The technical detail is basically we are using a bitmap under the hook to cache the complex path rendering, such that we can get the best redrawing performance, on a par with redrawing a bitmap drawable.
Let me know if scaleType='fitXY' can be a workaround for you , in order to get the image look sharp.
The marshmallow Vs Lollipop is due to a special scaling treatment added into marshmallow.
Also, for your comments:
"
Correct behavior:
The vector drawable should scale without quality loss. So if we want to use the same asset in 3 different sizes in our application, we don't have to duplicate vector_drawable.xml 3 times with different hardcoded sizes.
"
Even though I totally agree this should be the case, in reality, the Android platform has performance concern such that we have not reach the ideal world yet.
So it is actually recommended to use 3 different vector_drawable.xml for better performance if you are sure you want to draw 3 different size on the screen at the same time.
The technical detail is basically we are using a bitmap under the hook to cache the complex path rendering, such that we can get the best redrawing performance, on a par with redrawing a bitmap drawable.
dn...@google.com <dn...@google.com> #5
Yes, with scaleType='fitXY' the image looks great on Lollipop.
Thanks for the explanation, that makes sense.
I didn't read about this elsewhere, it might me a good idea to talk about it in the doc, to help other devs.
Thanks for the explanation, that makes sense.
I didn't read about this elsewhere, it might me a good idea to talk about it in the doc, to help other devs.
Ma...@htc.com <Ma...@htc.com> #6
Had the same problem, scaleType='fitXY' worked for me too. Thanks!
dn...@google.com <dn...@google.com> #7
Confirming both the bug and the scaleType solution.
Description
1. doing monkey test a whole day.
2. restart device.
- What happened.
System main thread may happened watchdog timeout when GMS calling UsageStatsService.queryEvents
but costs too much, because activity / pause usage event too mush in daily usage event file.
(as attachemnt for daily event xml file sample run by monkey test)
//watchdog timeout should be happened in this time but because delayed by UsageStatsService.queryEvents called by GMS
10-31 09:56:14.017 1351 1351 W art : Long monitor contention event with owner method=android.app.usage.UsageEvents com.android.server.usage.UsageStatsService.queryEvents(int, long, long) from UsageStatsService.java:720 waiters=1 for 91.896s
10-31 09:56:31.718 1351 1856 W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in handler on main thread (main)
//system server main-thread be blocked points
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x7323efa0 self=0xb8a5c328
| sysTid=1351 nice=-2 cgrp=default sched=0/0 handle=0xb6f96b44
| state=S schedstat=( 2593657022208 1661164362022 3429213 ) utm=183361 stm=76004 core=1 HZ=100
| stack=0xbe653000-0xbe655000 stackSize=8MB
| held mutexes=
at com.android.server.usage.UsageStatsService$1.onDisplayChanged(UsageStatsService.java:271)
- waiting to lock <0x0ccd17d8> (a java.lang.Object) held by thread 78
at android.hardware.display.DisplayManagerGlobal$DisplayListenerDelegate.handleMessage(DisplayManagerGlobal.java:467)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:168)
at com.android.server.SystemServer.run(SystemServer.java:350)
at com.android.server.SystemServer.main(SystemServer.java:235)
at java.lang.reflect.Method.invoke!(Native method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:797)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:687)
…
"Binder_6" prio=5 tid=78 Runnable
| group="main" sCount=0 dsCount=0 obj=0x138360a0 self=0xb9c35170
| sysTid=1913 nice=0 cgrp=default sched=0/0 handle=0x9003c930
| state=R schedstat=( 3550088585589 2264783707620 5548719 ) utm=290795 stm=64229 core=3 HZ=100
| stack=0x8ff40000-0x8ff42000 stackSize=1014KB
| held mutexes= "mutator lock"(shared held)
at java.lang.String.equals(String.java:431)
at org.kxml2.io.KXmlParser.getAttributeValue(KXmlParser.java:2038)
at com.android.internal.util.XmlUtils.readLongAttribute(XmlUtils.java:1556)
at com.android.server.usage.UsageStatsXmlV1.loadEvent(UsageStatsXmlV1.java:123)
at com.android.server.usage.UsageStatsXmlV1.read(UsageStatsXmlV1.java:234)
at com.android.server.usage.UsageStatsXml.read(UsageStatsXml.java:99)
at com.android.server.usage.UsageStatsXml.read(UsageStatsXml.java:63)
at com.android.server.usage.UsageStatsDatabase.queryUsageStats(UsageStatsDatabase.java:446)
- locked <0x095d56bb> (a java.lang.Object)
at com.android.server.usage.UserUsageStatsService.queryStats(UserUsageStatsService.java:315)
at com.android.server.usage.UserUsageStatsService.queryEvents(UserUsageStatsService.java:351)
at com.android.server.usage.UsageStatsService.queryEvents(UsageStatsService.java:728)
- locked <0x0ccd17d8> (a java.lang.Object)
at com.android.server.usage.UsageStatsService$BinderService.queryEvents(UsageStatsService.java:1216)
at android.app.usage.IUsageStatsManager$Stub.onTransact(IUsageStatsManager.java:103)
at android.os.Binder.execTransact(Binder.java:461)
----- pid 10800 at 2015-10-31 09:56:36 -----
Cmd line: com.google.process.gapps
…
"IntentService[LockboxService]" prio=5 tid=41 Native
| group="main" sCount=1 dsCount=0 obj=0x13cc9ac0 self=0xba43aea8
| sysTid=19170 nice=0 cgrp=default sched=0/0 handle=0x98afa930
| state=S schedstat=( 1934023469 775424381 1191 ) utm=170 stm=23 core=3 HZ=100
| stack=0x989f8000-0x989fa000 stackSize=1038KB
| held mutexes=
native: #00 pc 00043a24 /system/lib/libc.so (__ioctl+8)
native: #01 pc 00049e99 /system/lib/libc.so (ioctl+14)
native: #02 pc 0001ead9 /system/lib/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+132)
native: #03 pc 0001f217 /system/lib/libbinder.so (android::IPCThreadState::waitForResponse(android::Parcel*, int*)+38)
native: #04 pc 0001f463 /system/lib/libbinder.so (android::IPCThreadState::transact(int, unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+274)
native: #05 pc 0001a0bb /system/lib/libbinder.so (android::BpBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+30)
native: #06 pc 0008fef9 /system/lib/libandroid_runtime.so (android_os_BinderProxy_transact(_JNIEnv*, _jobject*, int, _jobject*, _jobject*, int)+280)
native: #07 pc 73235819 /data/dalvik-cache/arm/system@framework@boot.oat (Java_android_os_BinderProxy_transactNative__ILandroid_os_Parcel_2Landroid_os_Parcel_2I+140)
at android.os.BinderProxy.transactNative(Native method)
at android.os.BinderProxy.transact(Binder.java:511)
at android.app.usage.IUsageStatsManager$Stub$Proxy.queryEvents(IUsageStatsManager.java:232)
at android.app.usage.UsageStatsManager.queryEvents(UsageStatsManager.java:182)
at com.google.android.gms.lockbox.a.f.a(SourceFile:73)
at com.google.android.gms.lockbox.LockboxService.a(SourceFile:187)
at com.google.android.gms.lockbox.LockboxService.onHandleIntent(SourceFile:141)
at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:66)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:168)
at android.os.HandlerThread.run(HandlerThread.java:61)
…
proc 10800
thread 19170: l 10
outgoing transaction 144717221: d8932480 from 10800:19170 to 1351:1913 code 3 flags 10 pri 0 r1 node 3229 size 152:0 data c940058c
- What you think the correct behavior should be.
UsageStatsService.onDisplayChanged callback should be executed in another thread instead in system main thread.
-- OS version
android 6.0