Test: I solemnly swear I tested this conflict resolution.
Change-Id: I6f26542780c2b911e6aeea187c22e9d70823cd7a
Merged-In: I558447f282bb54f13be1622c3f2528a383fbc3b7
Test: I solemnly swear I tested this conflict resolution.
Change-Id: Ifeffa55c7fb80b0f327ecc5b50cefeca9db6457b
Merged-In: I558447f282bb54f13be1622c3f2528a383fbc3b7
The property is dalvik.vm.hot-startup-method-samples, setting this
controls how many startup samples are required before methods are
marked as hot in the profile.
Test: adb shell setprop dalvik.vm.hot-startup-method-samples 12
Test: adb shell setprop dalvik.vm.extra-opts -verbose:profiler
Test: adb logcat | grep Profile
Bug: 36457259
(cherry picked from commit 5eee004b92)
Change-Id: Ibf8075aafc6e5bd2ba10385973b26faee3d807df
There was 3 issues in this bug.
First the wrong stack id was used to defer and continue updating bounds
that broke a lot of the animation. This was fixed by using the recents
stack id instead of home.
Secondly, the wrong transit was passed into AppTransition.java getting
the wrong animation for recents to be docked, defering surface layouts
ensures that the correct transition is gained in that transaction.
Lastly, remove the starting window for the docked-by-drag-from-recents
transition because it was causing the window container to freeze its
bounds causing clipping issues and 2 flickers (where it appears over
the thumbnail) during the animation. Added a TODO to fix it later.
Test: go/wm-smoke
Bug: 34099271
Change-Id: Iaf0dffe5c2f5108c9946c9ea23c6e3fd6a49c34d
Previous patch ag/2250238 broke MtpDocumentsProviderTests since
ServiceIntentSender's constructor refers the context argument which is
null in the tests.
The CL adds a test version of the constructor which does not use the
context argument in it.
Bug: 38363487
Test: MtpDocumentsProviderTests
Change-Id: I68a1d8cb6997499e5069c33f70fd0f675aaad77c
(cherry picked from commit c5949bd39c)
It is possible that an activity in one stack may be reused in
another. For example, if an activity is started from a launcher
intent, but then is started from a home intent (from a
ResolverActivity). We currently do not move the activity, leading
to a inconsistency as the window manager proceeds to position the
task in the focus stack.
This changelist addresses the issue by using the reused activity's
stack rather than the computed stack.
Change-Id: Ie8a099e57e05a20b247bd0c97df8cda69e17c1bb
Fixes: 62402289
Test: go/wm-smoke
- There are several code paths from the loaders (which run on a background
thread) which post the call to notify an update on the task which was
loaded. Not all of these are cleared when a task is unbound, and can
result in a notifyTaskDataLoaded() after the task is unbound. For now,
just ensure that the TaskView is bound to the Task before updating.
Bug: 62194807
Test: Have not been able to repro, just ensure that recents thumbnails still
load
Change-Id: Id9301025275f4b14a2832f7f6c1ebd5a1ce124ea
