Allows option in tuner to switch between system theme overlays
if multiple exist. Requires a restart to take effect.
Test: Settings -> Tuner -> Other -> Theme
Change-Id: Iea43b9cbb67fd91c6008be594ad4cfd19c3f57ec
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
Test: Enable SysUI tuner, tap once on PIP to interact with the activity.
This is only experimental behaviour, and
android.server.cts.ActivityManagerPinnedStackTests will be updated
accordingly if we keep this behavior.
Change-Id: I278ab8c360c44718cfcac0fd761f476a875f9b15
Bug: 31781480
Test: make SystemUI, and manually inspected sysui appears in
Settings. Turning off sysui tuner still works.
The new alias is used by Settings to display sysui tuner in a different
category instead of in homepage directly. The display location is
controlled by category metadata. We need a alias because the category
metadata is different between new/old activity.
Change-Id: Ie4f2c1f6017459e34227155c83a7767f2003b18b
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
This was added to show policy transparency dialog with custom support
message, but the check is now removed so no need to hold this permission.
Bug: 30582906
Change-Id: Ica9d3ac052503cc2fe2c469e8b52cf0090959071
This was added to show policy transparency dialog with custom support
message, but the check is now removed so no need to hold this permission.
Bug: 30582906
Change-Id: Ica9d3ac052503cc2fe2c469e8b52cf0090959071
When the user does an "inline reply", we consider the notification
publisher app is "activated" and reset the shortcut throttling.
Bug 28705275
Change-Id: Ic9ffa13635274ead7e9d1e832cd31dea997830aa
This created extra churn in the system during resize due to
the activity relaunching.
Bug: 28614747
Change-Id: I148b6fca3dad7e10c90085a04bccb99587397912
* introduced a new intent DISMISS_KEYBOARD_SHORTCUTS and
and new public API in Activity (which sends a broadcast
to KeyboardShortcutsReceiver) which applications can
use to dismiss the keyboard shortcuts.
* plumbing and implementation for a new call to dismiss
keyboard shortcuts from PhoneWindowManager and used it:
** when starting activities invoked via Search+key
** when starting activities invoked via META
** when starting activities via application launch keys
* removed unused variable in
Activity#onProvideKeyboardShortcuts
Note that for apps started via touch (aka non-shortcut)
like tapping the Settings gear icon from the notification
bar the menu is not automatically dismissed.
Bug: 28012198
Change-Id: I83a8d4f342bb8a08115a648648834d0d2bac19fd
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
* changes:
Remove the highlight on the overview button in the screen pinning dialog
Fixing bad regression in alt-tab layout.
Workaround to ensure that a SystemUI process is always available.
- For a non-primary user, this CL will ensure that the SystemUI process
is started when we are switched to the user. This allows us to
maintain our current user-management model for Recents, which depends
on this process for preloading and state management.
Bug: 27175589
Change-Id: Id985fc2876e6daf06f303b44c0f9d1d3fd377842
This includes two fixes
- Restore PIP location when PIP menu is closed.
- Prevent PIP from moving to fullscreen when it's resized directly
via ActivityManager with animation.
These are regressions caused by
a0d4d25 PIP: Apply the animation spec for the PIP in Recents
Bug: 27540465
Change-Id: Id5b131faa3052a809138ab058bcfe65ce6a820b7
Add a callback to TaskStackChangeListener which gets fired when the system
might need to inform the user that a specific app might not work in
multi-window.
Use that callback in SysUI to show a translucent activity which scrims the
activity behind to inform that it might not be resizable.
Debounce the information to once per multi-window session, to not make it
annoying.
Introduce launchTaskId to start an activity in an existing task, and protect
that with START_TASKS_FROM_RECENTS permission.
Bug: 27327287
Bug: 27431869
Change-Id: I89e8d653872ab01ba3c1e252b426e5481da0e6ca
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
Second attempt. Still need to add strict mode violation checks and
logging.
Bug: 21901286
This reverts commit bf33bd4d31.
Change-Id: I5d73343544c32ce4fc4c377ba44db8e677a1287d
- Ensure that we start the screenshot as a foreground service to reduce
likelihood that it is killed while taking a screenshot.
- If the screenshot process times out or gets killed for any reason,
ensure that we update the notification with an appropriate error
message.
Bug: 27389179
Change-Id: I5007bda95538044bc753e4ceffd2f59a069c857b
Instead of resizeable attribute. resizeableActivity is what is used
for multi-window. The code currently works because it targets N :/
Change-Id: I82f1b1b46f66ea39ae682ed1d45f97bc6247b0bd
Move ChooserActivity to SystemUI. This is a safer place for it to live
and still be able to persist data to storage.
Add a context menu to long press for chooser targets allowing users to
'pin' a target component from an app. This causes it to sort to the
front of the list so that a user's favorite apps are always available
from share UIs, etc. Similarly, all ChooserTargets from a pinned
component receive an impossibly large boost for sorting so that they
will always appear first.
Bug 26791843
Change-Id: Ib4e603d9d4263403e98ce619287452ddab593044
