| 893f0bdcb73785ce0e06e9f935f5a7027cf77f14 |
|
01-Jun-2017 |
Jason Monk <jmonk@google.com> |
Add checks against incorrect context use in sysui tests
Fix incorrect usages found by this check.
Test: runtest systemui
Bug: 62251903
Change-Id: I45a762f96838e617833c1cbe003e583087bb8176
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 25a52b65b2cac1f49f37f4532cfa62282432957a |
|
23-May-2017 |
Jason Monk <jmonk@google.com> |
Add test to verify all sysui tests extend the right stuff
And then make it pass.
Test: runtest systemui
Fixes: 38500852
Change-Id: I377164219e4a4f4d1a99f11ef06da03c2b527eb0
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| e549a8d62108c7c7dabedbf4e77b9a653781723b |
|
15-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Optimize latency when unlocking phone
Latency when unlocking the phone regressed a bit for two reasons:
- For lockscreen -> app we now have to create a full starting
window containing the snapshot, while previously this was just
showing a surface.
- For lockscreen -> home, we can't use the saved surface anymore
because currently we don't support snapshotting translucent
activities. However, in the long term, we want home screen to be
more involved into transitions anyways, so we'll have to wait for
the first frame draw anyways.
However, crystal ball trainee developer Jorim added some
artificial latency in this transition 3 years ago, because he knew
that it is going to be an issue at some point so we have some
headroom to improve! Genius! On a more serious note, it was because
he didn't understand how to read systraces with binders involved (to
be fair, there was also no binder tracing).
Now, we can completely fix the introduces latencies above by
removing this latency of 100ms, and we are 30-70ms better than
before! However, this requires a lot of discipline in SystemUI.
Currently, the callback to dismiss Keyguard takes around 30ms. By
moving all non-essential binder calls of the main thread or to the
next frame, we bring this down to 5ms, such that window animation
and Keyguard animation starts about at the same time.
Test: Take systrace, unlock phone...profit!
Fixes: 38294347
Change-Id: I481fe4ecf358ed09f7142dd9e7ecd290b53c500c
Merged-In: I3ea672bc2eca47221bc6c9f3d7c56b6899df207d
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 340b0e5216b4fcc435e0459b1ca46155a572100d |
|
08-Mar-2017 |
Jason Monk <jmonk@google.com> |
Move out test utilities to a Testables library
Test: runtest --path frameworks/base/tests/testablets/tests
&& runtest systemui
Change-Id: Ideef4aef5f26136b1741c556b9be5884f38842a0
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 1d9632df97bdd4879cff0328a46a8fab6fde441a |
|
09-Feb-2017 |
Jason Monk <jmonk@google.com> |
New system for plugin + tuner integrations called extensions
An ExtensionController provides an easy way to say I need an
object of interface X. Then a plugin or a tuner factory can
actually provide X when needed or fallback to a default implementation.
Test: runtest systemui
Change-Id: I5e1b76def3c790d7f673867648ffeb13c4d0a829
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 09c43c874354aa5c34e90b1ac2d5179bc8ea21b3 |
|
09-Feb-2017 |
Adrian Roos <roosa@google.com> |
Dependency: Make non-class dependencies type-safe
Introduces a new DependencyKey<V> type which allows
referring to non-class dependencies in a type-safe
way. This also improves performance because we no
longer need to perform string comparisons.
Test: runtest systemui
Change-Id: Idc948855a85a1899be41e7f0170c40e73e525024
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| aa573e9e8632552d1fa8bdd6b0ee408ff9a93a6b |
|
27-Jan-2017 |
Jason Monk <jmonk@google.com> |
Work on separating out the status bar management
Lots of stuff:
- Make StatusBarIconController be a permanent dependency
- Break out dark stuff into DarkIconDispatcher
- Create StatusBarFragment
- This bit is a bit ugly for now, but will be better later
- Other stuff probably
Test: runtest systemui
Change-Id: I4973bc9f944e66af92731bf1edd2b39657f1782f
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| de850bbcaa61c1874b803f2086443febbafd81a4 |
|
02-Feb-2017 |
Jason Monk <jmonk@google.com> |
Fix leaks in sysui
Add support for testing for PluginManager and TunerService leaks
and add tests for the known leaks and fix them. Also port PluginManager
and TunerService to Dependency to make them easier to handle in
tests.
Test: runtest systemui
Change-Id: I5642539ee24dd72f802905106decd0c87b41b4eb
Fixes: 34846972
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 685db72eb7ddfeef29af1d191e67e0a041191f58 |
|
23-Jan-2017 |
Jason Monk <jmonk@google.com> |
Fix up the tests (yet again)
Turns out there was an actual bug in QSFooter where it was using
the wrong handler class (and not showing any of its security features),
and it would have been caught by presubmit if it was working...
Test: runtest systemui
Change-Id: Icbb19db1cc6f3f2a5f984618428ceb2899af69ab
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 9c7844cb91b43929d0a86b1c90aa1efb37f5463a |
|
18-Jan-2017 |
Jason Monk <jmonk@google.com> |
Work on sysui dependencies
One of the many problems with PhoneStatusBar is that it holds
dependencies for many other parts of SysUI. Fix this by creating
a static method of grabbing dependencies that are global to sysui
this cleans up a lot of chains of interdependence.
Also add easy way to inject mocks of these dependencies for the
purpose of testing.
Test: runtest systemui
Change-Id: Ia0e947faea62d15b665facada47ac9916c99f895
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 556cfb6a36d494f4e536b802f31924c56ee6d9c0 |
|
16-Dec-2016 |
Jason Monk <jmonk@google.com> |
Turn on dexmaker sharing classloaders for sysui tests
This will allow us to mock package private things. It also happens
to speed up the tests, a lot.
Test: runtest systemui
Change-Id: I48f39ee282a4ea3163c642c8290f302428c4a5f4
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 9abca5e9f88c47579f8334c6c48741a259185b9b |
|
11-Nov-2016 |
Jason Monk <jmonk@google.com> |
Cleanup and refactoring of test utilities
- Make leak checking faster by converting to fakes
- Requires making clean interfaces for all CallbackControllers
- Integrate leak checking into the TestableContext
Test: runtest systemui
Change-Id: Ic57a06360d01a0323ef26735a543e9d1805459e2
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| e97892844a5c21c91c7f82b96f82202b18a1a24d |
|
09-Nov-2016 |
Jason Monk <jmonk@google.com> |
android.provider.Setting test utilities
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
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 86bc33188948e7b6beb07dbb5ddba59b5ea3c1fc |
|
16-Aug-2016 |
Jason Monk <jmonk@google.com> |
Plugins for sysui
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
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 2c403db659db615831d8bd02661f8769c7762241 |
|
26-Aug-2016 |
Geoffrey Pitsch <gpitsch@google.com> |
Convert SysUI tests to use JUnit4
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
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|
| 930eccaf44239d010cbafb246651697996f567b5 |
|
12-Nov-2014 |
Chris Wren <cwren@android.com> |
Don't let the heads up close too quickly.
The public API of HeadsUpNotificaitonView was not well suited to the
new requirements, so it changed slightly.
Old API:
- showNotification: show or update a notification
- clear: close the window and forget the notification
- release: send the notification to the shade and forget about it.
- releaseAndClose: release and close the window
- dismiss: clear the notification if clearable, or release it
New API:
- showNotification: show a new notification
- updateNotification: show a new version of the same notification
- removeNotification: respond to a cancel
- release: send the notification to the shade at some point
- releaseImmediately: send the notification to the shade right now
The new API makes updating vs. posting and removing vs. releasing more explicit.
There is a new internal concept: lingering. The heads up lingers
after an event that would have closed it if the minimum visibility
time has not been satisfied. In the case that the notification was
deleted, the heads up may be visible, but mHeadsUp will be null. In
this case, touches on the notification views are disabled.
More responsibility for control of the heads of policy was moved into
the HeadsUpNotificaitonView class. This should continue on master.
Some changes to support testing.
Added a test to cover all the edge cases for minimum visibility time:
1. extend visibility when canceled too soon
2. extend when updated with a low-priority version, fast update.
3. extend when updated with a low-priority version, slow update.
4. don't extend the visibility in any other case
TODO: Policy parts of HeadsUpNotificationView should be split out
into a separate HeadsUpNotificationPolicy class, and even more of the
policy should be lifted from status bar that new class.
Bug: 17878008
Change-Id: I192419d0685dd022ee7edcd792e346a4f39c6adb
/frameworks/base/packages/SystemUI/tests/src/com/android/systemui/SysuiTestCase.java
|