summaryrefslogtreecommitdiffstats
path: root/packages/SystemUI
diff options
context:
space:
mode:
authorSvetoslav Ganov <svetoslavganov@google.com>2011-08-23 13:40:30 -0700
committerSvetoslav Ganov <svetoslavganov@google.com>2011-08-24 16:26:43 -0700
commit8bd69610aafc6995126965d1d23b771fe02a9084 (patch)
tree13d160fbe865f3febd084c9935e38b1f5360ee84 /packages/SystemUI
parent69314e72941c86734c12476d1e61459811159b74 (diff)
downloadframeworks_base-8bd69610aafc6995126965d1d23b771fe02a9084.zip
frameworks_base-8bd69610aafc6995126965d1d23b771fe02a9084.tar.gz
frameworks_base-8bd69610aafc6995126965d1d23b771fe02a9084.tar.bz2
Intra-process view hierarchy interrogation does not work.
The content retrieval APIs are synchronous from a client's perspective but internally they are asynchronous. The client thread calls into the system requesting an action and providing a callback to receive the result after which it waits up to a timeout for that result. The system enforces security and then delegates the request to a given view hierarchy where a message is posted (from a binder thread) describing what to be performed by the main UI thread the result of which it delivered via the mentioned callback. However, the blocked client thread and the main UI thread of the target view hierarchy can be the same one, for example an accessibility service and an activity run in the same process, thus they are executed on the same main thread. In such a case the retrieval will fail since the UI thread that has to process the message describing the work to be done is blocked waiting for a result is has to compute! To avoid this scenario when making a call the client also passes its process and thread ids so the accessed view hierarchy can detect if the client making the request is running in its main UI thread. In such a case the view hierarchy, specifically the binder thread performing the IPC to it, does not post a message to be run on the UI thread but passes it to the singleton interaction client through which all interactions occur and the latter is responsible to execute the message before starting to wait for the asynchronous result delivered via the callback. In this case the expected result is already received so no waiting is performed. bug:5138933 Change-Id: I382e2d8689f5189110226613c2387f553df98bd3
Diffstat (limited to 'packages/SystemUI')
0 files changed, 0 insertions, 0 deletions