It was caught in the code review after the merge (thanks Narayan!).
This is already fixed and tested in the internal branch (see Merged-In)
Test: manual, CTS in internal
Change-Id: I9f6f72995e9ab633564b6bc22846fbe99eb65105
Merged-In: If14126e645b2d0a1307404e2f50088b3994abce2
This new command is used to attach runtime agents to a running application:
attach-agent <PROCESS> <FILE>
Attach an agent to the specified <PROCESS>,
which may be either a process name or a PID.
Test: m test-art-host, manual testing:
. invalid syntax, missing arguments
. invalid syntax, extra arguments
. invalid numeric PID
. invalid process name
. valid process, not debuggable
. valid process, missing agent
. valid process, valid agent
Bug: 31682382
Change-Id: I61cc8bf20addb1702acc8e7aae65b2f9ed7c5ca0
Merged-In: Ife88dbf23991dde7945d9208e54cd014bb7ecdc6
The request network with timeout was originally created with a
check of max timeout against a constant of 100 minutes. However,
the API was not public and did not implement a timeout. Any users
were internal and never got any onUnavailable() callback (since
timeout never triggered).
There is no reason to have a max timeout so the constant is
remove.
Bug: 31399536
Test: unit tests and CTS of ConnectivityManager
Change-Id: Icbedfb4299d75b6a7e3e43720111531f1faafd06
- This fixes an issue where the last stack active time would be clobbered
when switching between users. With the policy in the phone/stack
recents, this is fine, but with the grid recents, it no longer only
applies when out of the historical window, so it is always wrong (it
would normally be wrong if switching back from another user after the
historical time of six hours).
This CL will migrate the last stack active time to a per-user secure
setting, which will be used going forward.
[This is a manual merge of change 1913535]
Bug: 35375206
Test: On the Ryu, launch some tasks, switch users, launch more tasks, and
return to the original user
Change-Id: Idc72920240093d15f822f5d9e3ee11b12a56edae
We already does this on start. Now we also do the same when
the list of options changes.
Test: locally on device
Bug: 34470067
Change-Id: Ib184d67b532c5afd584fb9cd52daac69a7c50d0a
The offset used to adjust MotionEvents for swipe velocity tracking
was incorrect, and caused issues when touch points where close
together. Fixed the offset used, which resolved swiping issues.
Bug: 34673753
Change-Id: Ide6060b511510bcf299e3db778e6ffc6afda5e19
ConnectivityManager static sCallbackHandler is referenced and directly
used in a way that is not ensuring its proper initialization.
This patch fixes this potential NPE by using getHandler() instead.
Also this patch changes sendRequestForNetwork's signature to only accept
the subtype CallbackHandler instead of Handler: without using
CallbackHandler the NetworkCallbacks are not triggered properly and
bookkeeping of sCallbacks does not happen. sendRequestForNetwork's
signature now makes this explicit.
This step prepares the addition of overloaded versions of
registerNetworkCallback and cie that takes custom Handlers.
Test: build, flashed, manually checked connectivity
Change-Id: I52e8a2cb5075e7aef7b35e30c9845cacba927d13
Cancelling swipe-to-dismiss will trigger a check to ensure the window
is reset to its original state. Ensure that the reset is actually
required before setting the new layout attributes.
Bug: 34816397
Change-Id: Idf26ce7c8b63dc44a76effefcb32eb8d8665f605
