- Refactoring SoundTriggerHelper to handle generic sound models.
- Ability to store multiple models, callback and state information.
- Separate out initialization to be done per voice model, per any model
and per generic model.
- Minor change to the API exposed -- removing the Handler from the
createSoundTriggerDetector call.
- Added callback processing for onRecognitionEvent().
- Added logic for stopAll().
- Changes to the SoundTriggerTestApp to start/stop recognition.
- Multiple models (3).
- Ability to start/stop/load/unload individual models.
Bug: 22860713
Bug: 27222043
Change-Id: Ie5d811babb956bead653fb560a43f1e549ed11bd
Don't continue to check idle states for removed / stopped users.
No need to check for uninstalled packages for all users.
Bug: 27208519
Change-Id: I9a3a3bbec560dd380ce90df9fef102d7f62769ca
This change makes StorageManager.getVolumesList(),
StorageManager.getPrimaryVolume(), and StorageVolume public and adds a
buildAccessIntent() in the latter to automatically generate the
ACTION_OPEN_EXTERNAL_DIRECTORY intent, but it doesn't change the
ACTION_OPEN_EXTERNAL_DIRECTORY implementation yet (i.e., it still takes an URI with the physical path of the directory, instead of a StorageVolume and
a directorny name).
BUG: 26742218
Change-Id: I36c59c42b6579e125ec7f03c3af141260875a491
It is a mistake that we put contact id in PhoneLookup._ID.
But for SIP query, the contact id is put in Data.CONTACT_ID instead.
For backward-compability issue, we can't revert the change, but to
save developer from having logic like below, PhoneLookup.CONTACT_ID is
introduced.
if (sip) {
get contact id in Data.CONTACT_ID column
} else {
get contact id in PhoneLookup._ID column
}
So for sip query, we put contact id in PhoneLookup.CONTACT_ID.
For other phone lookup query, we put contact id in both PhoneLookup.ID
and PhoneLookup.CONTACT_ID.
BUG:27149017
Change-Id: I4155da29bbacdda0d43164b0ce11c7224a4eee67
If there was another layout happening before the app called
relayoutWindow(), we were issuing multiple reportResized calls,
leading to multiple relayoutWindow() calls, slowing everything
down.
Change-Id: I1f3da04bb7581c655567e1d1a6fe0f8c83c0ffda
Delegating to the TrustManagerImpl doesn't work correctly with
getAcceptedIssuers, do it in NetworkSecurityTrustManager instead.
Bug: 27124116
Change-Id: Ie527d63aaa115e6137396e07c7d134b1c42bfe87
am: a086f0436a
* commit 'a086f0436ad600915db1f8e0dc284d653d152e8d':
Using AppWidgetHostView in RemoteViewsAdapter instead of managing the RemoteViews inflation itself
am: e619e33b60
* commit 'e619e33b606dbdd885d5379a6f1fd60636ff59a2':
DO NOT MERGE Extend the DownloadManager.addCompletedDownload() method to support origin details.
This is a preparation for File-Based Encryption (FBE) support in IMMS.
In order to support File-Based Encryption (FBE), IMMS needs to reset
its internal state exactly when the device is unlocked by user first
time. This is important because IMMS would recognize only
encryption-aware input method services until the the device is unlocked
by the current user.
Even if we reset the internal state when the device is unlocked by the
current user, there are still two tricky points.
1. Except for the initial boot, IMMS uses Secure Settings to determine
what IMEs are enabled and what IME is currently selected. These
persistent state may not be suitable for the situation where the
device is not unlocked yet, because some of IMEs referenced there
may or may not be encryption-aware. Depending on the situations,
we may need to enable at least one encryption-aware IME to ensure
that the user is able to type password to unlock the device, even if
such an IME is not Settings.Secure.ENABLED_INPUT_METHODS. We have
to be careful when doing this because we don't want non
pre-installed IMEs to be enabled until the user approves it.
2. IMMS tends to save its internal state into Secure Settings.
However, because of the point 1, we may need to automatically enable
a certain IME to make sure the user is able to type even when the
device is not unlocked yet. We don't want such a temporary state
to be persistent in Secure Settings.
The basic idea of this CL is to implement Copy-On-Write (COW) mode in
InputMethodSettings so that we can later discard any changes made before
the device is unlocked. As the initial step, we start using this COW
mode until the the ActivityManager becomes ready. With this change we
can revert a previous commit [1] for Bug 6685037, where forward-locked
encrypted apks need to be taken care of an early boot phase.
[1] Ifb311f85154beadd4787ec73669bedfdf1f5172d
4c0e7152e7
Bug: 26279466
Change-Id: I9c6f9bb3d51174198e5f73588637f87ea0d90e11
