Send a broadcast back and forth to speed up the rate at which plugins
are enabled or disabled.
Also update make files to handle exclude tests better.
Test: Manual
Change-Id: Ic8f45c663c3a5e5fd4b3e9e2f79480e155845c14
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
Looks like SystemUI's manifest may be corrupt.
This reverts commit 91f576081fe67f2742980f75c17d11e36f7c60e1.
Bug:29939875
Change-Id: I06e5f3cbc4629a67d254a8fcfcb9749b317aef5f
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
Moves the protos and event log tags into a library,
so the build system doesn't think they're duplicates.
Bug: 27151225
Change-Id: Ic96b6b811d4813a4c48940081ea77b12fb23f0bc
First of several change lists:
1. Add in the new proto (this CL)
2. Migrate the existing code over to the proto.
3. Remove MetricsConstants once it is unused.
Bug: 26442178
Change-Id: Ic24829246af8ec5b202e39a85960aac5cf336c33
- Initial changes to show a history view within Overview (behind tuner
flag)
- Restoring the task view dim in the stack
Change-Id: I0503d11768736c86f3145942404391dfacd0ddd6
- Removing old broadcasts in favor of direct aidl interface between
system and secondary users. Also moving user specific implementation
into RecentsImpl, allowing Recents to handle proxying between users.
Change-Id: I4bd5ef1d1ee47309b7c754f50a5e8b2e2aab988f
Added a new component which tracks touch and sensor events and
also events like showing the bouncer tapping a notification and
others. The collection is enabled when the screen is turned on and
is disabled after the phone is unlocked. The data is saved in a
protobuf file in internal storage in a directory called
"good_touches". There is also an option to collect events which
end with the screen turning off. These are saved in the
"bad_touches" file. Everything is hidden behind the
ENABLE_ANALYTICS flag which is set by default to false and can be
turned on only if Build.IS_DEBUGGABLE is true. Also
behind the ENFORCE_BOUNCER flag the class shows the bouncer before
expanding a notification, showing quick settings or launching an
affordance from one of the bottom corners.
Change-Id: Iaeae0fb7a0d9c707daf7a270201fa5b1cd84c74a
Ideally, we would also do incremental builds on userdebug targets,
but this introduces a risk that userdebug builds would be different
to user builds. So we only do it on eng builds for now.
Change-Id: I2778d270052cf26e6c767f1847991a425d8bbd12
Setting the environment variable EXCLUDE_SYSTEMUI_TESTS to something
excludes the tests package during building. Saves a few seconds for
incremental changes in SystemUI for fast UI iteration changes.
Change-Id: I596a0273133c8a8bece0cc364e2ec61fdea45116
This change achieves a couple of things:
- Let Keyguard be a library, so we can use it in SystemUI.
- Introduce FLAG_KEYGUARD for windows and deprecate TYPE_KEYGUARD. Make
all the TYPE_KEYGUARD behaviour dependant on the flag.
- Implement a new KeyguardService in SystemUI, and bind that service
from PhoneWindowManager.
- Introduce BaseStatusBar.setKeyguardState and inflate
KeyguardSimpleHostView there and use FLAG_KEYGUARD for the window, such
that the status bar window essentially gets the Keyguard.
Bug: 13635952
Change-Id: I059d80d8b9b9818a778ab685f4672ea2694def63
"signatureOrSystem" permissions are no longer available to all apps
residing en the /system partition. Instead, there is a new /system/priv-app
directory, and only apps whose APKs are in that directory are allowed
to use signatureOrSystem permissions without sharing the platform cert.
This will reduce the surface area for possible exploits of system-
bundled applications to try to gain access to permission-guarded
operations.
The ApplicationInfo.FLAG_SYSTEM flag continues to mean what it is
says in the documentation: it indicates that the application apk was
bundled on the /system partition. A new hidden flag FLAG_PRIVILEGED
has been introduced that reflects the actual right to access these
permissions.
At some point the "system" permission category will be
renamed to "privileged".
Bug 8765951
Change-Id: I6f0fd9cdb9170e076dfc66d83ecea76f8dd7335d
These have been created to reduce the size and complexity
of frameworks/base.
mms-common was created by moving all of
frameworks/base/core/java/com/google/android/mms
to:
frameworks/opt/mms
telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony
Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
