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
Bug: 5205674
Only wake the device on positive interactions from the user
such as button presses, movement, initial touch down events.
In particular, do not wake the device on up events since the
driver might synthesize them on power off, causing the device
to wake up again for no good reason.
Change-Id: I767f553ea36d110e6f3a10611b324487ba7d880d
Instead of polling every 15 minutes, register for alerts that trigger
when system-wide traffic passes a threshold. Still mixed with polling
to persist UID stats, but relaxed to 30 minutes. Currently watches
for every 512kB.
Make persistence decision separately for network versus UID, and use
total delta bytes when making decision. Use light bootstrap during
systemReady() instead of heavy poll, which had been force-loading all
UID data unnecessarily.
Bug: 5023631
Change-Id: I04b723d6c4bf872fb1028071122dba66a8e1b576
Add policy controls to NetworkStateTracker which are combined with
other user preference and internal flags to decide if data connection
should be established. Better locking around enabled flags.
When data network would be over limit, proactively disable data on
that network. Enable when policy is snoozed or when cycle resets.
Track and dismiss notifications from now-stale policies.
Bug: 4587023, 5178147
Change-Id: Ibfcc9f73cda7c369209af701b46eddd3d1943f2d
The new specification calls for LED to continue blinking until the user
pulls down the notification shade in the status bar.
Bug: 5143247
Change-Id: Id004cc3d1d9d76108329e57c6fbd8a8100068e0a
Signed-off-by: Mike Lockwood <lockwood@android.com>
Bug: 5205301
Some drivers report one finger as BTN_TOOL_FINGER, two as
BTN_TOOL_DOUBLETAP, three as BTN_TOOL_TRIPLETAP and four
as BTN_TOOL_QUADTAP. Since we care about the tool type,
we need to handle _DOUBLE/_TRIPLE/_QUAD tap in the same way
we handle _FINGER.
Change-Id: I8eb83d2a2bada9ac32d07619c7eea84e924316b8
