It wasn't properly lazy-initializing the service binder, so it always
thought the backend service didn't exist, and so always returned false.
Also directly validated that every usage of sService in the module is
now correctly lazy-initialized.
Bug 16661321
Change-Id: If5fbb18aef81bfa8fd70eb40a1f6af54cc96d804
Currently, users' preference in phonebook and call history or message
access per each Bluetooth-paired device is stored in Settings application's
shared preferences.
However, some privileged applications other than Settings need to access
such data. So we decided to migrate the data from Settings application's
shared preferences to Bluetooth application's.
Bug: 17158953
Change-Id: I3771f03eaea3f57cf60d93ab9fd41c9eb3e1e99c
Bug 17440475
transitionAlpha must be set when using Transition.forceVisibility,
but shouldn't be set when views initially come into the scene.
Change-Id: Icc61c83c701508d09dadb074c86094171dcce78a
While we're in there also call listeners when they're added
so they know the state immediately.
Bug: 17258031
Change-Id: I5f1186314795f3fafd78e1b3e2d5102cdaec65d6
When META-INF/MANIFEST.MF is missing, treat as NO_CERTIFICATES
instead of CERTIFICATE_ENCODING. Also remove redundant layer of
debugging details when wrapping exceptions.
Bug: 15667982
Change-Id: I6e8216d5bf6e42da1feb70c89f991001380305be
ActionMenuViews work in two modes: hosting another Menu instance or
creating their own. The former is used when an action bar is
displaying a window's options menu. The latter is used when an
ActionMenuView (or Toolbar) is placed within an arbitrary layout and
the getMenu method is called.
When showing a window's options menu, ActionMenuPresenter calls into
the ActionBarPolicy to determine if we should reserve an overflow
button or if overflow will be presented by the window instead. Always
reserve overflow if the ActionMenuView is presenting its own menu.
Bug 17381966
Change-Id: I17c495986994d421bf6276ae39ba233243432e97
Simulates the relevant portions of a DOWN/UP event pair to request focus
and bring up the IME.
BUG: 8213791
Change-Id: Idb32d81552ecbbdefc64686c914eba6d8e28b0b8
Since implementation is still largely synchronous, this is safe.
For the future full-asynchronous implementation, this is the behavior
we want in any case.
Bug: 17345630
Change-Id: Ib54a3441b21fa8cb42bcc6548e5639d9db7ec193
Otherwise, cannot reliably match up capture progressed and failure callbacks
with the start callback.
Bug: 17421092
Change-Id: I91d92be70a15536b215bac330370ce37e426ec26
This can be controlled by MDMs via DPM.
Also fixes:
- javadoc for restrictions
- persisting of cross profile copy/paste restriction
Bug: 17387303
Change-Id: Ie148f56189181d2a4c6345c0823d417ab13a94a3
- Both are move to FileChooserParams, remove UploadHelper class.
- createIntent only handls non-capture intents
- parseResult is the static member of FileChooseParams and should
be used with createIntent.
BUG:17253647,16624450
Change-Id: I81cac7c1b739880db4e4c1f2b4612ed2ee87cb1b
There was a race where ActivityManager would return null
for getCurrentUser() when switching between guest accounts.
This is because the Guest account was marked for deletion
while it was still active.
Bug:17290209
Change-Id: I224fb4b6836380e5acb7dbeb8f3343d74505f88a
(Noticed the difference in a javadoc diff between Notification and
NotificationCompat)
Bug: 17424399
Change-Id: I639a46c429ffebf8ca47118b2ea80f40ccdc1286
