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
Fixes a bug where the keyguard message area would reorder clears
after a new message was set, leading to the bouncer prompt reason
not showing.
Change-Id: I33001300d9175c521809cd4fdae5158269245c00
Fixes: 32306174
Test: runtest -x $T/frameworks/base/packages/SystemUI/tests/src/com/android/keyguard/KeyguardMessageAreaTest.java
Not meant to be an attempt at full coverage, just an example of
testing a Drawable.
To go farther with this, I would wrap the "logic" of the battery
appearance in a separate class for testing and this class would
reduce to the drawing operations, which are strongly coupled to
design and don't need much testing.
Test: runtest systemui
Change-Id: I5630e25face9a3ab5e30935fb3d7bab8f162d107
Cache ClassLoader by pkg so that Plugins can talk to each other.
Also add some filtering so that only classes from the plugins package
and sub-packages are included in plugin classloaders.
Test: Manual
Change-Id: I42aabb418168d5a5d0581b8133aa93f07cb7e977
Just a sample - this is a far cry from full coverage. Mostly
exercises the handoff to the NotificationManager. To go further,
I would verify more of the Notification contents.
Modified the constructor to explicitly take a NotificationManager,
mocking out the Context wasn't feasible here.
Change-Id: Ic83ef17f061a20efc52b7e3e8c022afab2deacdb
There's a lot of variance in the network tests, but this appears
to save ~1 second when running them all.
Change-Id: I4629f8d123313a5acf3ff076f0a5960719e35f13
Changed to be purely a unit test, no inter-system integration.
Context binds are mocked, uses verify to check callbacks directly.
Parameterize the bind retry delay so tests can set to zero.
Change-Id: I798823c7c79978261fceac26002f819e3800c711
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
Slices ~10 seconds off the systemui target test time.
Wrapped calls to the different PackageManager APIs with
PackageManagerAdapter, which should change to a cleaner
abstraction as we write more tests.
Change-Id: I91ac9959de05a06ed484e49648203729159a482e
Different mockito library for junit4.
This causes class loading failures for them but not our builds.
Change-Id: Iae4ba584f83e0ab78505fa822a74f5998fbca395
- This CL does two things, firstly, it ensures that all first & last
active times are monotonically increasing and independent of the
current system time. This allows us to better keep track of which
tasks are historical and should be hidden, and which are not.
Secondly, this CL moves the tracking of the last visible active time
into the system (per user) where it can be adjusted along with the
task active times when they are loaded.
- Following this CL, all active times in the future will be adjusted on
boot such that old tasks are made relative to the current boot time.
It’s not important exactly what time they are, only that they are
adjusted along with the last visible task active time so that we
always keep track of what is visible.
Bug: 28908500
Change-Id: I4f789df3a6bd825517cf3a70e26fb60deff89d06
Run tests with android.support.test.runner.AndroidJUnitRunner,
modification to runtest target in separate CL.
No longer inherit from TestCase, stripped unneeded code from
SysuiTestCase, which now assigns mContext via
InstrumentationRegistry.getTargetContext().
Can no longer create Handlers with default constructor,
Looper.myLooper() was never able to receive messages in tests
and it is now enforced that you pass the Looper.getMainLooper().
Change-Id: I13f499175a459cef1a554431911f4b21126e126e
Looks like SystemUI's manifest may be corrupt.
This reverts commit 91f576081fe67f2742980f75c17d11e36f7c60e1.
Bug:29939875
Change-Id: I06e5f3cbc4629a67d254a8fcfcb9749b317aef5f
Evidently some apps redirect/obscure tiles in a way that makes
creating a ComponentName from the TileService useless. Instead
generate a token which will be a much more stable way of identifying
tiles henceforth.
Change-Id: Id68550bcdcdc3e3987f09380f258610e7a5aca85
Fixes: 29121793
am: 6815912e3b
* commit '6815912e3b928faf3113498e4bc3d0b0172abc57':
Don't show data disabled icon when user isn't setup
Change-Id: I3971a2b524f4c506b9cbe8e474819dfa31019b99
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
Since the mode of a tile service was set in onTileAdded, it couldn't
be controlled by developers if they updated their tile. To handle
the mode has been moved to a boolean meta-data flag to indicate
a tile should be an active tile.
Bug: 28043969
Change-Id: I6403d34f8cb70809edc07769389d5a1f835c1ab3
