Set up a base class for testing fragments that will generate the host
and run the fragment through some lifecycle checks to make sure it
does ok with standard lifecycle.
Fragment tests will also automatically check for any sort of leaks
related to bindings, receivers, or other callbacks in sysui. This
requires changing the statusbar.policy classes with callbacks to
have a common interface.
Lastly also fixes a few lifecycle bugs in QS found from the above
tests.
Bug: 32609190
Test: runtest systemui
Change-Id: I52007c696c2fd41914bba4ba9d8055f2b564a7d8
Add a way to fake values for settings in tests. Since the content
provider is cached in the NameValueCache, there is one static
FakeSettingsProvider that passes through all values to the
real SettingsProvider by default. Values that are required for
the test can be acquired and locked for the duration of the test
easily.
Test: runtest systemui
Change-Id: Ibc31ac8509fb31a22c522358a9c1bae6ec63553b
Pulls appart UI, state, power, display and trigger management
into individual components controlled by a state machine.
Also adds tests.
Test: runtest -x packages/SystemUI/tests/src/com/android/systemui/doze/DozeMachineTest.java
Change-Id: I6ee7e79d58a5a3ebeb975775af44ad1e5aaccf93
This is a simple first version in the spirit of small, incremental CLs.
It is fully functional but the following will come in later changes:
* Split screen support
* Potential animations
* Alt-tab behavior
* Relayout on orientation changes
The new activity is only started when a specific system property is set.
Test: Locally on Ryu device. Added tests for layout logic.
Bug: 32101881
Change-Id: I550f6e7ea0de3937dbf80e5f0294676cfe567d47
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
- 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
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
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
Do this by making SignalCallbacks send out initial state immediately
rather than posting this state. This requires a little refactoring
to how SignalControllers work.
Bug: 27061469
Change-Id: Iba6b91a4a5d1d13cce0f0d308b6f85f0340bff39
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
- Add startActivityAndCollapse, to make collapsing the shade easy
- Add isSecure()
- Add isLocked()
- Add unlockandRun(Runnable)
- Add unavailable, active, and inactive states
The states are added to allow consistent UI across OEM devices, by
allowing UI tweaking and tinting to match system tiles with custom
ones.
The combination of isSecure() and isLocked() and unlockAndRun(Runnable)
allows all combinations of launching show when lockend and triggering
an unlock when needed for sensitive tiles.
Change-Id: Iade98ad9f2c22aa174e62090d8ccd44c86f3bb3c
