When writing a rule matching fields and methods at the same
time, only the name '*' is authorized.
Bug: 34916285
Change-Id: I90cb8273f0915e216940faa1b3d9c6e82296798f
It is a relic of a more complex time, but has passed out of all
knowledge for too long.
Test: manual testing on phones and TV
Change-Id: I62a15d9413ea4bda3ac82bf6f7d22c096e2c1cdc
Why this is safe:
- To never ever be used in production code, simply for rapid
prototyping (multiple checks in place)
- Guarded by signature level permission checks, so only matching
signed code will be used
- Any crashing plugins are auto-disabled and sysui is allowed
to continue in peace
Now on to what it actually does. Plugins are separate APKs that
are expected to implement interfaces provided by SystemUI. Their
code is dynamically loaded into the SysUI process which can allow
for multiple prototypes to be created and run on a single android
build.
-------
PluginLifecycle:
plugin.onCreate(Context sysuiContext, Context pluginContext);
--- This is always called before any other calls
pluginListener.onPluginConnected(Plugin p);
--- This lets the plugin hook know that a plugin is now connected.
** Any other calls back and forth between sysui/plugin **
pluginListener.onPluginDisconnected(Plugin p);
--- Lets the plugin hook know that it should stop interacting with
this plugin and drop all references to it.
plugin.onDestroy();
--- Finally the plugin can perform any cleanup to ensure that its not
leaking into the SysUI process.
Any time a plugin APK is updated the plugin is destroyed and recreated
to load the new code/resources.
-------
Creating plugin hooks:
To create a plugin hook, first create an interface in
frameworks/base/packages/SystemUI/plugin that extends Plugin.
Include in it any hooks you want to be able to call into from
sysui and create callback interfaces for anything you need to
pass through into the plugin.
Then to attach to any plugins simply add a plugin listener and
onPluginConnected will get called whenever new plugins are installed,
updated, or enabled. Like this example from SystemUIApplication:
PluginManager.getInstance(this).addPluginListener(OverlayPlugin.COMPONENT,
new PluginListener<OverlayPlugin>() {
@Override
public void onPluginConnected(OverlayPlugin plugin) {
PhoneStatusBar phoneStatusBar = getComponent(PhoneStatusBar.class);
if (phoneStatusBar != null) {
plugin.setup(phoneStatusBar.getStatusBarWindow(),
phoneStatusBar.getNavigationBarView());
}
}
}, OverlayPlugin.VERSION, true /* Allow multiple plugins */);
Note the VERSION included here. Any time incompatible changes in the
interface are made, this version should be changed to ensure old plugins
aren't accidentally loaded. Since the plugin library is provided by
SystemUI, default implementations can be added for new methods to avoid
version changes when possible.
-------
Implementing a Plugin:
See the ExamplePlugin for an example Android.mk on how to compile
a plugin. Note that SystemUILib is not static for plugins, its classes
are provided by SystemUI.
Plugin security is based around a signature permission, so plugins must
hold the following permission in their manifest.
<uses-permission android:name="com.android.systemui.permission.PLUGIN" />
A plugin is found through a querying for services, so to let SysUI know
about it, create a service with a name that points at your implementation
of the plugin interface with the action accompanying it:
<service android:name=".TestOverlayPlugin">
<intent-filter>
<action android:name="com.android.systemui.action.PLUGIN_COMPONENT" />
</intent-filter>
</service>
Change-Id: I42c573a94907ca7a2eaacbb0a44614d49b8fc26f
Cars usually have an external audio module. When Android is serving as
the car's headunit, users should be able to adjust the car's volume
through SystemUI. The following changes are made to make it work:
+ Load VolumeDialogController from SystemUIFactory
+ Added CarSystemUIFactory
+ Added CarVolumeDialogController which extends VolumeDialogController
and it uses CarAudioManager as source of truth for volume controls.
+ Some refactor in VolumeDialogController to make it easier for
subclasses to override volume controls.
Note that CarAudioManager does not completely replace AudioManager.
Majority of code in VolumeDialogController still applies in the car use
case, so I made CarVolumeDialogController a subclass of
VolumeDialogController instead of making them peers.
Bug: 27595951
Change-Id: Id4adec7281e41aa71f3de034e5b88a32a89be305
- Exposing members of PhoneStatusBar, StatusBarKeyguardViewManager and
KeyguardBouncer to sub class;
- Add a configuable SystemUIFactory as class factory for components;
- Add logoutCurrentUser and switchToByUserId to UserSwitcherController;
BUG:22407003
Change-Id: I3902baf3c721d89217b27a6310c4202a198cb209
This change adds in the beginnings of System UI for
the automotive use case. We extend the Phone status
and navigation bar and override the parts which are
customized for auto.
The navigation bar itself is built from a resource
array specified in car_arrays.xml to allow of ease
of customization of the shortcuts that are in the
navigation bar.
Bug: 26301185
Change-Id: I780a2ef9dd5ae2a4be9355b5874d08f521a86fa7
- Now, all task views will be bounded by the stack rect, and the
thumbnail bitmaps will be scaled accordingly to fit either by width
(when stacked) or to the view rect (when freeform)
- Fixing issue where the history button was not offset in freeform
- Tweaking thumbnail sizes of fullscreen screenshots
- Still requires changes to fix clipping to the correct aspect ratio in
freeform.
Change-Id: I678b87c2f06947d32f3bb7c60a35f28eb36b5a68
- Adding “focused” stack state to support paging
- Changing the paging to match UX spec (only auto-page after the first
tap)
- Removing old header focus animation
Change-Id: Id72825b8a1b1c0a2238ee184a6695b13c1d8cb1c
- Moving to a couple piecewise curves to define the various overview
layout states. Added a new state for focus (to be used in follow up
CL) to control paging of overview from the nav bar button. This
allows us to control the visible range of items on the curve, and
to better fit other UI controls around the stack.
- Removed the scaling of the tasks in the stack
- Also refactoring parametric curve to just use the system Path
Change-Id: I4108da77986d86896576e36fa8f31189d6fcb6f3
- Initial change to use the event bus by dispatching
package events directly to the TaskStackViews instead
of passing them down the view hierarchy manually.
Change-Id: Ic68df9eeefb79eab8ded84b74264a93719b40643
The new MediaProjection infrastructure allows the system to hand out
tokens granting the ability to capture the screen's contents, audio,
etc. at a granular level. It's intended to be used both for screen
casting, via the cast APIs, as well as screen sharing via third party
applications.
The screen sharing case is implemented, but all of audio capturing
is still forthcoming.
Change-Id: I4b24669bed7083e11413c10ed8d6b025f5375316
For kiosk-type devices that do not present any navigation UI. This allows
for clean selection of the implementation based on resource overlays,
without the need for the tablet or phone status bar implementations to
accomodate the desired behaviors.
Bug 5824373
Change-Id: Idcec70eef437904edda452b69e5eb7a3cc7094f7
(cherry picked from commit 5717f80927944c141f059162ecd69649488f8049 in ics-aah)
Signed-off-by: Mike J. Chen <mjchen@google.com>
Not yet wired up to FLAG_FULLSCREEN; right now you must
invoke it manually by longpressing on the clock area.
Bug: 2905073
Change-Id: I43a005f2e4c08edb3673aef523bcaa1e088e8a71
