A ChooserTargetService can be implemented by apps that wish to offer
additional deep-link targets for the system intent chooser to in turn
offer to the user. This allows apps to create contextually relevant
shortcuts for UI flows that would otherwise require several steps of
explicit disambiguation. For example, a chat app might offer one-touch
access to recent conversations when sharing a photo to it from
elsewhere.
The chooser implementation must limit the number of
ChooserTargetServices it elects to query in order to respect available
system resources. Only the system chooser is permitted to bind to a
ChooserTargetService.
Change-Id: Ia7e075ee649c51cf2035f20aee166c5a27d91aeb
This patch refactors construction of StaticLayout to use an explicit
Builder object, which is intended to hold state used for constructing
the layout but not needed for merely reading out the results.
Builder objects are allocated from a pool and explicitly recycled,
so there is insignificant additional allocation cost.
This patch has very little impact on performance (it does avoid
allocating a FontMetricsInt object) but opens the way for significant
performance and functionality improvements as more of the Builder
functionality migrates to native code.
Change-Id: I2a576643e573a38b61f895a80d5d92a85c94b6b4
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
User might update playback rate while calling Play on a sample.
Update sample rate if reusing existing audio track.
Change-Id: I7007c335fa405baf663a322408b92b9df53efdb0
Signed-off-by: Glenn Kasten <gkasten@google.com>
Reuse channel for same sample if the channel completed
current playback and is not reallocated to another sample,
i.e. not stolen by other sample.
authored-by: Ashish Jain <ashishj@codeaurora.org>
Change-Id: Ibe7ee318c7dc11f3c4fd3a2f57d861318b10973b
Signed-off-by: Glenn Kasten <gkasten@google.com>
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
