UICC privileged carrier apps will extend CarrierConfigService to provide
carrier-specific configuration. Apps/services will use
CarrierConfigManager to read the current configuration.
CarrierConfigManager also defines the set of configuration variables and
their default values.
Bug: b/19483786
Change-Id: I027211b43276afd6fe893ae50048c52f2aed5cf5
- Allow apps to read and modify notification policy (currently
which items are prioritized in "priority only" mode), but only
after they've been granted access by noman.
- Access to read/modify notification policy requires a token provided
by noman. Enabled notification listeners are automatically given
tokens (new getter on NLS), but any other app can also request them.
- Currently, all requests are granted.
- Also add a new change intent when the public policy changes.
Bug: 18541928
Change-Id: I482d1c39852d0d961931515e0f0e059a8faee4ed
Previously we had to wait for systemReady before setting the brightness
due to the order in which the display power controller was initialized.
Unfortunately it could take us a rather long time to reach that stage,
particularly after an OTA where the screen would remain at maximum
brightness for minutes while "Optimizing Apps".
This change moves the brightness backlight setting code deeper
into the display manager which has a couple of nice side-benefits
in that it now becomes much easier to coordinate display power mode
changes with display backlight changes. So this change also resolves
some issued with changing the backlight while in DOZE_SUSPEND and
ensuring that backlight changes generally end up being performed
before executing a power mode change except in the case where the
display needs to come out of suspend first. (So now the backlight
will be set before entering DOZE from the ON state.)
Deleted some dead code in LightService which was in the way.
Bug: 19029490
Change-Id: I494b5223e676248daf2ff8be3ec338845977f73c
- When starting a voice interaction session from SysUI, a callback
can be passed to know when voice interaction has successfully started
- Add a new window type for the voice interaction starting window,
which resides behind the voice interaction layer.
- SystemUI now also inspects the voice interaction service to get the
logo asset for the starting window.
- Make VoiceInteractionSession window fullscreen, to accomodate for
the visuals.
Change-Id: If8c3c445e8b39841f48e8d153e6d1ba81e447286
More S's for More Speed
Split JankTracker's backing data from the
class to allow for data relocation to/from ashmem regions
Pack the jank tracking data to fit in 256 bytes
Change-Id: Ife86a64b71a328fbd0c8075fe6a0404e081f725b
New flag you pass in to startSession() to say you want it,
new callback on VoiceInteractionSession to receive it.
Change-Id: I61fdcfdee41a60d46036a2ef16681a9b4181115a
Also add API for voice interaction service to control
whether the system should hold a wake lock while it is
working with an activity (and actually *do* hold a wake
lock while doing so, duh!).
And while in there, clean up the launching wake lock to
correctly give blame to the app that is launching.
Change-Id: I7cc4d566b80f59fe0a9ac51ae9bbb7188a01f433
Optimize parceling of AssistData (which is now renamed to
AssistStructure) by pooling duplicated class name strings.
Change text associated with a view node to a CharSequence,
so styling information comes along.
Include global text attributes -- size, colors, etc.
Introduce a new AssistContent structure, which allows us
to propagate information about the intent and data the
activity is looking at. This further allows us to propagate
permission grants, so the assistant can dig in to that data.
The default implementation propagates the base intent of an
activity, so if for example you bring up the assistant while
doing a share the assistant itself has the same information
and access that was given to the share activity (so it could
for example share it in another way if it wanted to).
Did some optimization of loading PersistableBundle from xml,
to avoid duplicating hash maps and such.
Changed how we dispatch ACTION_ASSIST to no longer include
the more detailed AssistStructure (and new AssistContent)
data when launching; now the example code that intercepts
that needs to be sure to ask for assist data when it starts
its session. This is more like it will finally be, and allows
us to get to the UI more quickly.
Change-Id: I88420a55761bf48d34ce3013e81bd96a0e087637
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
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
- Change the package name from android.midi to android.media.midi
- Add option for specifying a Handler for DeviceCallback notifications
Change-Id: Ia9e9817a651c06299f4e02ee1da3c9666ff64cb9
We continue to compile external/apache-http into ext.jar. This contains
a few changes apart fom the classes moving around :
- Makefile changes to build docs and api-stubs for now. A future change
will revert these changes and remove these classes from stubs and
docs.
- Hardcode event IDs in legacyerrorstrings to avoid a dependency between
the frameworks and apache. These strings are on their way out and will
never change anyway.
- Remove imports due to {@link} tags and use {@code} instead.
- Remove an accidental(?) dependency on apache commons code that's a
part of apache-http.
bug: 18027885
Change-Id: I51cd038d846ec7d02c283a4541b10a6a9cf62ecf
MIDI ports are now implemented as file descriptors directly between the sender
and receiver, so the MidiService is no longer in the message path.
To facilitate the above, each port has its own file descriptor, rather than multiplexing
all ports on a device through a single socket.
Added a new class MidiDeviceServer, which is used by implementors of MIDI devices.
This replaces the MidiVirtualDevice class (which only was included in changes that were reviewed but never submitted).
The USB MIDI implementation has moved from the MIDI service to the USB service.
The USB MIDI implementation uses MidiDeviceServer as its interface, so we now have a common
interface for all MIDI device implementations.
Change-Id: I8effd1583f344beb6c940c3a24dbf20b477a6436
This replaces IKeystoreService.java with IKeystoreService.aidl and
changes the methods that passed down a byte[][] to instead pass down a
KeystoreArguments which is currently a thin parcelable wrapper around a byte[][].
Change-Id: I6367bcf57562f41a27aab14f1903b74995cb65c2
Still to do:
Add MidiInputPort and MidiOutputPort classes
Schedule sending MIDI events in the future
Security/permissions
Reconsider interface for virtual devices
Look into performance optimizations
Change-Id: I9b7d63b196996a04be0a830efa913043da1328a8
Add new flag for an app to define it doesn't duck, but rather
pauses when losing focus with AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK.
This flag is to be used when requesting focus.
Add support for AudioPolicy to specify whether it will implement
ducking itself, rather than it being handled by an app.
When ducking is handled by a policy, do not notify focus owners
when they lose audio focus with LOSS_TRANSIENT_CAN_DUCK, unless
they would have paused, as expressed with the
AUDIOFOCUS_FLAG_PAUSES_ON_DUCKABLE_LOSS flag.
Add a focus listener for a policy to be notified of focus changes
so it can properly implement its own ducking.
Bug 16010554
Change-Id: I11d7cdb85c52fd086128a44f4d938aaa44db5c25
