To reduce the number of times that we load resources based on
configuration changes ActivityThread employs an optimization
strategy that merges relaunch operations. If it receives a
relaunch request why one is already queued, it will just update
the queued request instead of creating a new one. Unfortunately
this breaks the guarantee of executing lifecycle events in the
order they were received.
Consider following scenario of requestes from Activity Manager:
1) relaunch the activity in not resumed state;
2) resume the activity;
3) relaunch the activity in resumed state.
The Activity Thread can process these commands in following order:
1) receive the request to relaunch in not resumed state;
2) receive the request to resume the activity;
3) receive the request to resumed state, update the exisiting
request;
4) execute the request to relaunch in resume state;
5) execute the request to resume.
This causes the activity to perform resume twice.
Since we need the merging of relaunch operations for performance
reasons, we need to introduce a secondary mechanism for ordering
of lifecycle requests. Relaunching, pausing, stopping and resuming
receive a sequence number based on when the request was received. If
the last executed sequence number is higher then the operations
sequence number then the operation will be dropped.
In the above scenario the sequence number would be:
1) request to relaunch not resumed receives seq + 0;
2) request to resume receives seq + 1;
3) request to relaunch resumed receives seq + 2;
4) execution of of request to relaunch resumed set current sequence
number to seq + 2;
5) since seq + 1 < seq + 2, then the execution of request to resume
is prevented.
Bug: 24806374
Change-Id: Ia520dd1aa215827d4172a9891a7cc01db2ce627e
Currently required for apps like recents to resize correctly
with the 2-render thread approach. Eventually we will want to
separate the functionality from the non-client-decor.
Bug: 24742523
Bug: 24810450
Change-Id: Id241bf8fe47dd8c4ec570c90149c859c45aa6285
This makes it so that the socket cannot receive datagrams from
anybody except the DHCP server. This does not improve security,
because we never read from the UDP socket anyway, but it does
make ListeningPortsTest pass.
Bug: 23906864
Bug: 23933386
Change-Id: I82fe9d6c6c520536ffd6422bcc60fab664999e6f
This change grants Android Wear system components default
permission.
I have also added a new Intent category to help identify
the main Home handler on Wear.
BUG: 23419042
Change-Id: Ie669a9908bd3b03498f75c5ca22c0fddf52a5203
Introduced some regressions. Reverting until we can do better testing.
This reverts commit 8375d63998.
Change-Id: I9b15d63e52c814ef8985b86f8a50359e39355d39
Return a valid value for the current play time if the animator has
been seeked to a play time or fraction, but not yet started.
Issue #24717972 animator.getCurrentPlayTime() is all messed up
Change-Id: I15f1329b65410b4b0366a23a3419b5987305a865
Prevents multiple-threads from accessing/changing member variables at
the same time that can lead to the app crashing.
Also, setName on ResizeFrameThread so we can easily find it in systrace.
Bug: 24745288
Change-Id: Ic2fc7d661db5360c13314197c40e8b2315d2b7e5
When activity doesn't have a non client decor view but we preserve its
windows, we need to remove the children directly from the decor view
instead.
Bug: 24750271
Change-Id: I50e83ef61deba92e668ee165c4a297547a56071f
When the user clicks X in non client decor of a freeform task, we
don't want it to be removed from recents. The task gets finished,
but it will remain in recents.
Bug: 24718309
Change-Id: I8f47e310903ee7f839ec92f5c8ff3a9f1e09118c
Status & nav bars are always visible and opaque when freeform or docked
stack is visible
We still need to refactor the code to allow force opaque to be updated
independently for the status bar and nav. bar. Once that is done, the
status bar should be transcluent if freeform stack is visible and
docked stack isn't and the status bar should be opaque if freeform
& docked stack are both visible.
Bug: 24365214
Change-Id: I48ecc6067c9b0f7239c12c98eb46f3fcefacd4f9
This CL makes webview override View#onActivityResult and gives webview
itnernals the access to View#startActivityForResult.
BUG: 24416313
Change-Id: Ia49db1348a1f5ee0c648a8b16551d9becc7caddd
In the case of scaled SurfaceViews with a fixed size.
It is possible for the surface layout size to change
without a change to the surface size or position. In this
case we need to inform the window manager so it can update
frames and scaling. This has presented in Camera and required
workarounds such as changing the fixed surface size to trigger
an update (leading to visual artifacts).
Bug:23974105
Change-Id: I195aa0832907c32874b294101b56e198e853dce5
(cherry picked from commit a8fe43f09c)
In the case of scaled SurfaceViews with a fixed size.
It is possible for the surface layout size to change
without a change to the surface size or position. In this
case we need to inform the window manager so it can update
frames and scaling. This has presented in Camera and required
workarounds such as changing the fixed surface size to trigger
an update (leading to visual artifacts).
Bug:23974105
Change-Id: I195aa0832907c32874b294101b56e198e853dce5
