TelephonyRegistry notifies wrong state thourgh onDataConnectionStateChanged().
As a result, browser works even though there is no data icon in status bar.
The issue is reproducible as following senario:
1. There are two connections.
2. Network type is changed and one of the connections is disconnected
at the same time.
3. TelephonyRegisitry notifies disconnect state to apps which are listening
PhoneStateLinstener.
Change-Id: Iac1e2b14e41715a63ea0d842cb44d232447e814a
Signed-off-by: yoonsung.nam <yoonsung.nam@samsung.com>
Change to use a real item alarm for scheduling ACTION_TIME_TICK
intents for the case where time goes backwards after the tick intent
is schedule, and where the time change is not noticed from the call
to waitForAlarm().
Bug: 5166877
Change-Id: I46b9a1c80146d27becedc341c4af977fcdf47352
Change-Id: Iff2cfec5280a314989d915aa830c16124f921611
5214105: taking a screenshot while "Android is upgrading..." crashes device
5109947: Race condition between retrieving a content provider and updating its oom adj
When taking screenshots we need to use the full drawing state list
instead of the visible list.
Bug: 5186823
Change-Id: I214ee0203aaf8e2c038e44581f7f1ae36edf08c5
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
When recording data usage, measure the actual active time, since
buckets can be quite long. Offer incrementOperationCount() version
that reads thread stats tag for caller. Rethrow any NPE as ISE
during stats parsing, which callers already handle.
Bug: 5171812, 5184508, 5180659
Change-Id: I6da80ccc0162be68bee279529e3a23b6f98ebd87
We now use Intent.makeRestartActivityTask() to build the notification
PendingIntent objects, so that when tapped they restart the activity
in the desired state.
Fixes bug 5011926
Change-Id: Ie1ec3543cc0f49d1bd407622a617316cf53a078c
