Retrieving list of methods in every invoke() call is very expensive.
Caching the list inside the constructor prevents several unnecessary
calls to Class.getMethods().
Test: Run camera2 CTS
Bug: 62490715
Change-Id: Ib2a93af0f364b055df2eab9bd7870730428429ad
I will not pretend classes are interfaces...I will not pretend
classes are interfaces...
Bug: 62444724
Test: cts-tradefed run singleCommand cts -d -o --module CtsViewTestCases --test android.view.cts.SurfaceViewSyncTest#testSurfaceViewBigScale
go/wm-smoke
Change-Id: Iccca46edcd669430c32f31e9c7d8aba1db254f2d
- Move the bounds animation onto the animation thread
- Remove existing code referencing the old sf-vsync choreographer
- Add ability for ValueAnimator subclasses to reference a different
AnimationHandler, which uses a different FrameCallbackProvider with the
sf-vsync choreographer in the animations that require it
- Ensure that PiP touch events are batched and sent aligned with the
sf-vsync
- Move GC onto its own thread to not block other BackgroundThread calls
Bug: 36371375
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: bit FrameworksServicesTests:com.android.server.wm.BoundsAnimationControllerTests
Test: go/wm-smoke
Change-Id: I6a41b35a4e4d4d6dbea82c2673452825fe3ffa58
Allows for dumping the activity state during the last anr. This will
also be included in collected bug reports.
Bug: 38121026
Test: Cause an anr to occur and run 'adb shell dumpsys activity lastanr'
Change-Id: I1e4200f9e5cc16bfab98e5af31fc599cdd54cd11
View already checks if its layout is being updated when calling
notifyEnterOrExitForAutoFillIfNeeded(), but that doesn't prevent apps crashing
when the autofill process was triggered by another view.
Test: existing CtsAutoFillServiceTestCases pass
Fixes: 38198484
change-Id: I8e9435ddc4cf21fb648d39aace93f3af0e1fdf4f
- Add new Choreographer instance that runs on vsync-sf
- Use this new Choreographer for WindowAnimator, and remove all
the hacks around it
Test: Open apps and close apps, notice no stutter
Test: Screen zoom animations
Test: go/wm-smoke
Bug: 36631902
Change-Id: I988ae25645effc3ac20efa7cb9b68f23444da0d0
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
bit CtsWidgetTestCases:android.widget.cts.EditTextTest
Bug: 62271937
Change-Id: Ib3447281f3bd1abc811a25fc55ad55e34e155bbb
This cl adds the following data in BatterySipper
1. screenPowerMah: power smeared by screen
2. proportionalSmearMah: power need to smeared proportionally
3. displayPowerMah: smeared power usage
This cl also copies bunch of methods from BatteryUtils to
BatteryStatsHelper with minor changes, so we could log smearing
logic in BatteryStatsHelper
Bug: 62300864
Test: runtest -x BatteryStatsHelperTest
Change-Id: I9f92f5c1ac5fa483d0c15a3d5daad570da68a7ff
Merged-In: I9f92f5c1ac5fa483d0c15a3d5daad570da68a7ff
Bug 62188967
A previous change stopped animations on fragment Views before
being removed. This change in behavior caused other problems,
so the behavior must be placed behind a target SDK check.
Test: ran fragment tests, validated on app
Change-Id: I098e9b0f1472d9838abeacba3baaa7581f7a82ad
Because cloning wasn't synchronized, the notification
could become a non-root temporarily which in turn could
lead to a crash.
1. We're now properly synchronizing the cloning, such that
this can't happen anymore
2. We're now only cloning the old statusbar notification lightly
instead of heavily to avoid this altogether
Test: manual, update decoratedcustomview notifications really fast
Change-Id: Ia6525eec64ad9a26956ca2198e20198f55b2173c
Fixes: 62181033
Sometimes callers want to clear the calling identity [to avoid permission
calls]. In this case, allow passing the original calling identity to
internal methods.
Test: Manual; create profile account and observe launcher still works cross profile
Test: bit FrameworksServicesTests:com.android.server.pm.ShortcutManagerTest{1..10}
Change-Id: I73f8ad4b2dc1895227c3fcb14f3f1f18f600562f
Fixes: 38349978
It has been discovered that for background values of
AggregatedWakelock, Sync, Job, and partial wakelocks,
the value of getTotalTimeLocked is wrong and often very
negative. getTotalDurationMsLocked, which should provide the exact same
value in all of these cases (since background data is never pooled),
does not have this problem. So while the source of the bug is sought
out, we should use getTotalDurationMsLocked instead of getTotalTimeLocked for
these data.
Bug: 62352334
Test: cts-tradefed run cts-dev -m CtsDumpsysHostTestCases -t android.dumpsys.cts.BatteryStatsDumpsysTest
Change-Id: I78e84368615578483ab8e9e5f0ee1d067491be08
