This adds the ability to enable or disable target icons based on the drawable
resource of the target.
It also fixes a bug where we'd show the camera while displaying
the PIN/PUK unlock screen or when it's disabled by DevicePolicyAdmin.
Minor simplification and cleanup KeyguardUpdateMonitor callbacks.
Change-Id: I33fad56a2203bc8b7bcd0300c20478711a56713a
There is no graceful way to kill Android application processes.
They typically have many threads running doing various things
When System.exit() is called, those threads just keep going
while the cleanup actions run until the process finally.
Performing shutdown actions can easily cause more harm than good.
For example, closing the Binder driver's file descriptor may
cause other threads waiting on Binder to wake up and then crash
in nasty ways after receiving EBADF.
So when an Android application exits, skip the cleanup and just
call _exit() to end it all.
Bug: 6168809
Change-Id: I29790c064426a0bf7dae7cdf444eea3eef1d5275
Refactor SMS Cell Broadcast support to enable receiving CMAS warning
notifications over CDMA. The CellBroadcastReceiver app must also be
updated with the corresponding change. All cell broadcasts are now
delivered as a Parcelable SmsCbMessage object in the "message" extra
of the SMS_CB_RECEIVED_ACTION or SMS_EMERGENCY_CB_RECEIVED_ACTION,
instead of as a GSM/UMTS "pdu" byte array.
Existing functionality for ETWS and CMAS alerts over GSM/UMTS continues
to be supported using the new radio-technology independent SmsCbMessage
and related objects. Test cases are added to verify that valid and
invalid broadcast data is handled appropriately.
Unit testing discovered a bug in the BitwiseOutputStream utility class
used by the added test cases. When the BitwiseOutputStream object must be
expanded (in the private possExpand() method), the mEnd field is not
updated to the new array size. This causes a new array to be allocated
on every new write, and for all data beyond the original array allocation
to be replaced with zeroes. Fixed by adding a line to possExpand() to
update mEnd. Added a test case to BitwiseStreamsTest to verify the fix.
Besides the test cases, BitwiseOutputStream is only used by BearerData in
two places, both of which allocate a sufficient initial buffer. So the
bug in BitwiseOutputStream is not critical to fix for normal operation,
but should be fixed so that the test cases using it function correctly.
Bug: 5856308
Change-Id: I201ecbf11607fd200aaae3cbb32561efabf65672
Bug #6120957
Using this new callback, views can interrupt and resume their
animations or other periodic tasks based on the current state
of the display.
Change-Id: I398f4abd421e9c5f207107bf1009a7b92cf45daa
Bug 5712010
Fix cases where the transition between split/standard action bar menu
presentation wasn't happening properly for windows in activities that
handle their own config/orientation changes.
Change-Id: I7168555e09c9ed448afb8619fd6f0e1466695365
When WindowManagerService's events are enabled/disabled, the state of the
display is dispatched to the known windows. This allows ViewRootImpl to
ignore draw requests until the screen is turned back on. This can potentially
lead to significant battery savings. For instance, a launcher widget showing
a repeating animation will cause the CPU and the GPU to wake up regularly
without this change.
(Change submitted by Intel and merged manually)
Change-Id: I7f93b0e60c3e6de1705f619e80860c36b1cdb978
Watches for package changes so it can dynamically adjust
to reflect the actual list of available activities.
Change-Id: I3a2fef3dac4d13d1b2a7ed6fc117a7b814679669
Fix the current asynchronous API to use callback like the way
was done with p2p API.
In the process, fix the use of WPS
Change-Id: Ib6f8714cf51b3525b655948268804e7eaaf17587
Refactor SMS Cell Broadcast support to enable receiving CMAS warning
notifications over CDMA. The CellBroadcastReceiver app must also be
updated with the corresponding change. All cell broadcasts are now
delivered as a Parcelable SmsCbMessage object in the "message" extra
of the SMS_CB_RECEIVED_ACTION or SMS_EMERGENCY_CB_RECEIVED_ACTION,
instead of as a GSM/UMTS "pdu" byte array.
Existing functionality for ETWS and CMAS alerts over GSM/UMTS continues
to be supported using the new radio-technology independent SmsCbMessage
and related objects. Test cases are added to verify that valid and
invalid broadcast data is handled appropriately.
Unit testing discovered a bug in the BitwiseOutputStream utility class
used by the added test cases. When the BitwiseOutputStream object must be
expanded (in the private possExpand() method), the mEnd field is not
updated to the new array size. This causes a new array to be allocated
on every new write, and for all data beyond the original array allocation
to be replaced with zeroes. Fixed by adding a line to possExpand() to
update mEnd. Added a test case to BitwiseStreamsTest to verify the fix.
Besides the test cases, BitwiseOutputStream is only used by BearerData in
two places, both of which allocate a sufficient initial buffer. So the
bug in BitwiseOutputStream is not critical to fix for normal operation,
but should be fixed so that the test cases using it function correctly.
Bug: 5856308
Change-Id: Ie3e6af747976ce9b8a3e71e76fec71709cf86545
When pdu's are removed from the PduCache, make sure we remove
them from the list of pdu's currently being updated as well.
Change-Id: I45dde4a09d74019a344fca31e3926b1ece6c393d
Optional titles will only be displayed in the CAB if they entirely fit
instead of ellipsizing.
Fixes bug 5821883
Change-Id: I0cfd6d4fd34a4fa9f520499d577706da30606811
As said in https://android-git.corp.google.com/g/#/c/155992
finishComposingText is indeed too broad of a method.
Introducing a new dedicated method to warn the InputConnection.
Should solve the problems with a negative counter value.
Change-Id: I5525d776916f0c42d5e6d4a4282aed590d7f0e9a
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
This change introduces a few new bits of data on
Notification that will help the Notification Manager and
System UI route and display them more intelligently:
-> priority: an integer in a predefined range that
indicates the app's best guess as to the relative
importance (to the user, right now) of that information
-> kind: a tag (really, set of tags) indicating the general
type of notification (realtime, asynchronous, etc)
-> extras: a Bundle of additional key/value pairs
associated with this notification (currently @hidden)
The notification manager takes these data into account when
assigning to each notification a score which is passed with
the notification on to the system UI, where it can be used to
affect presentation. For example:
- Spammy apps (identified explicitly by the user or by
some other means) will have their notifications scored
very negatively by the notification manager, allowing
the UI to suppress them
- Notifications of higher score might be shown larger
or in a different way
- Very important notifications (indicated by a very high
score) might interrupt the user during an otherwise
important task (videochat, game, etc)
Implementation note: This replaces/extends the old internal
notion of "priority", which was mostly used to organize
ongoings and system notifications at the top of the panel.
Change-Id: Ie063dc75f198a68e2b5734a3aa0cacb5aba1ac39
Remove the right-to-left cascade effect from action mode menu
items. Animation time is now fixed at 300ms for scaling in menu items.
Change-Id: I8eef2ed9f93c2af804663dd5e6b3f4915ed45cb1
