To implement a virtual MIDI device, include a subclass of MidiDeviceService in
your application. This service is identified by an intent filter and meta-data
in the application's manifest to allow the MIDI manager to register the virtual device
without actually running the application. Instead, the application's MidiDeviceService
subclass is started on demand when MIDI manager clients want to open the device.
Here is an example of how the MidiDeviceService might be described in the application manifest:
<service android:name="VirtualDeviceService">
<intent-filter>
<action android:name="android.media.midi.MidiDeviceService" />
</intent-filter>
<meta-data android:name="android.media.midi.MidiDeviceService"
android:resource="@xml/device_info" />
</service>
and the device_info.xml meta-data:
<devices>
<device manufacturer="Sample Manufacturer" model="Sample Model" private="false">
<input-port name="my input port" />
<output-port name="my output port" />
</device>
</devices>
(note that the <input-port> and <output-port> names are not currently used, but support for these
will be added in a subsequent change)
Client's of the virtual device will bind directly to the hosting application's MidiDeviceService subclass.
To support this, MidiManager.openDevice() now returns the MidiDevice asynchronously via a callback.
This change also adds a utility class called MidiDispatcher, which is a MidiReceiver
that dispatches all data it receives to a list of other MidiReceivers.
We now use this internally in MidiInputPort and MidiDeviceServer, but developers
may use it for other purposes as well.
Change-Id: Ic3009f06d56f3d5edbd87de3f0c330b51a1c217d
We also log when notifications are actually canceled,
so this only tells us how often clients cancel non-existent
notifications. The answer: quite often.
Bug: 19599876
Change-Id: I812866cb080d51974d4db0b6e6b3eb50c3aeb560
Also enables the swipe from top gesture for revealing
the navigation bar, even if the status bar is visible.
Bug: 19282730
Change-Id: I7b562c2f0f00ff3f05b8b1e44657efe79b45f9c7
A device initializer is an application that is allowed to run
during user provisioning on device owner devices. During
device provisioning (or, user provisioning of the first user
of the device), a device initializer is granted device owner
permissions. During secondary user provisioning, a device
initializer is granted profile owner permissions. Once
provisioning is complete for a user, all elevated permissions
are removed from the device initializer and the device admin
component of the app is disabled.
Bug: 19230954
Change-Id: Ib6725fb3b09bb21e4198a5dc0b445ccebb40b27e
Currently is only used for tracking the daily charge
and discharge rates. We keep up to 10 days of data.
Change-Id: I54e29e35ff60d9277da9e476cdab22f4a6d540bf
Problems arise if an activity is started in an ActivityView when the
parent activity is not resumed. In particular the ActivityView can
be brought to the front in front of other activities that have been
started by the parent.
This change checks the state of the parent when the ActivityView is
starting and if it is not resumed, throws an Exception.
This change also removes the queueing up of Intents if the surface
does not exist when startActivity is called. Now, the owner of the
ActivityView is notified when the surface becomes available. If
startActivity is called before that notification an Exception will be
thrown.
Fixes bug 19147472.
Change-Id: I6712cf1929fe65c4238ce7f3feb4e8511ed97244
Instead of a runs-forever periodic alarm that drives key/value backup
passes, we instead schedule-on-demand a trigger job that will kick off
the pass after a batching interval. The key semantic change is that
we now never wake for key/value backup work unless we've been explicitly
asked to do so. We also use a rather longer batching interval than
was previously the case.
Bug 19536032
Change-Id: Ie377562b2812c9aeda0ee73770dfa94af6017778
This would cause an exception to be thrown when querying stats
that included a deleted file and cause only in-memory stats to be
returned.
This change now re-indexes after deleting files.
Furthermore, we continue reading UsageStats files in order
to return more useful data if some other issue (file corruption)
leads us to fail reading a file.
Change-Id: I4a52739624d68e719e3d7d324a0b16709a62ac7a
This will allow for updating a package's last time used
property for packages that are interacted in ways other than
launching their activities (interacting with notifications, etc.)
Change-Id: Ic6f9519f46fa04abd37ea6fc9475bcd9ea721003
If you try to disable USB debugging before the socket
to listen is opened in the thread, it will end up
with an NPE.
Do some locking around socket creation and closing
to avoid this.
Bug: 18708503
Change-Id: Iac43e4806fff1e411772b1ba1a070d8a7c776fcb
The current SELinuxPolicyInstallReceiver logic can yield a partial
or mixed (old and new) set of policy files under /data/security/current
if there is an error or a crash at certain points before completing
the installation of the update.
Rewrite the logic to avoid the possibility of such partial or mixed
policy updates by using rename on the entire directory of policy
files rather than operating on a per-file basis. Also separate
the extraction of the policy files from the bundle into their own
temporary directory. Make sure we delete any previous temporary directory
or backup directory before using them for this update. Drop the
use of a symlink for /data/security/current altogether; it provides
no benefit.
Change-Id: I564af01c2c3ca1531c216013b8724c7511f32de8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
- cleanup thread issue and simplify native FingerprintService methods
- add new permissions and enforce them
- add fingerprint hardware detection API
Change-Id: I87c2243ea2412061f1e85b044138480d0161bcdf
