The mockito-updated-target-minus-junit4 target was added because
some tests needed a later version of mockito than was available
through mockito-target-minus-junit4. Since the latter has now
been upgraded to 2.7.13 that is no longer true and so users of
mockito-updated-target-minus-junit4 can be switched to use
mockito-target-minus-junit4 instead.
Bug: 32912773
Test: make checkbuild && runtest systemui
Change-Id: If7e4dd26d7d0e93731856e9739a048c89a835333
This CL adds the APCT tests within this project to
a similar suite as CTS known as device-tests.
The current method of running APCT tests in the infrastructure
is unaffected.
Bug: 35882476
Test: `make dist device-tests -j` and local builds of
continuous_instrumentation_tests & continuous_native_tests
Change-Id: Ifa382fe691842c1cd76897775b9e2a1653449eb5
In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.
(cherry picked from 6387604f9e672ece85e07c4bcbd7be396867f06f)
Bug: 30188076
Test: make checkbuild
Merged-In: I13e88297731253420e4e5f5291d503f13a39a156
Change-Id: I58446eb8c45d8ac2bcdbc9fa40d1321e811bdd4b
In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.
Bug: 30188076
Test: make checkbuild
Change-Id: I13e88297731253420e4e5f5291d503f13a39a156
Some updates required for tests to pass. Also did a little cleanup
of bad verify matching.
Test: runtest systemui
Change-Id: I75b9f34ab7e9af111dafd5a648840893e1cee434
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
Different mockito library for junit4.
This causes class loading failures for them but not our builds.
Change-Id: Iae4ba584f83e0ab78505fa822a74f5998fbca395
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
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
- 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
Now you can run the tests without getting the blank broken sysui.
The tests instrument themselves so they include all of the source
they need to run rather than piggybacking on the sysui process.
A couple of changes were needed for this. The xml files cannot
reference com.android.systemui, instead they must use res-auto.
The tests can no longer make privileged calls, so some restructuring
to avoid those calls was needed.
Bug: 18222975
Change-Id: I67b794af854f1420583d48960bd6e52ca753b56d
Add some tests that verify for varios wifi, and mobile signal
strengths and types that the correct icons are sent out in the
callbacks. Still in prep for MSIM refactoring.
Bug: 18222975
Change-Id: I477bf9a90e5c32fb1cba9c150ec6314f4b707108
This will allow us to add some test cases to verify that under
certain phone/signal conditions we get out the icons we expect.
This will let us break less things when refactoring for MSIM.
Bug: 18222975
Change-Id: I7bd3e66e7de6b30fede72e40fb6aa37dd523336c
