SINGLE_TOP is only guaranteed to work within the current task stack.
If multiple stacks are inactive in the background (eg. temporarily
switching from freeform mode to fullscreen mode by maximising one
activity) some tasks might get missed out and stay visible.
Test: manual -- start two work activities, one in fullscreen & one in freeform. start a personal
Test: activity in freeform too. switch to the fullscreen work app and lock the profile using
Test: `adb shell service call trust 6 i32 $USER_ID i32 1`
Test: __outcome after change__
Test: a) locking work profile should bring up the work password prompt in fullscreen
Test: b) skipping the prompt and switching to the personal freeform app should keep the freeform
Test: work app hidden by WorkLockActivity
Test: __outcome before change__
Test: Only (a) happened, for step (b) the work app was still visible
Bug: 31001762
Change-Id: I5979c5b12670a21c7bcd59e222fc518d395e3e29
No longer need to look up the application info, target SDK is
explicitly passed in to the check. For the external method, we
change this to just checked to see if background is completely
disabled, which doesn't need a target SDK check (and is the only
thing any of the current clients care about).
Now allow SystemUI to put targets of notification pending intents
on the temporary whitelist when they fire, so developers can avoid
dealing with background restrictions in this case (if the user
interacts with their notification, they will temporarily be
considered in the foreground).
Remove any thoughts of enforing restrictions on registerReceiver(),
so we don't need to deal with target SDK versions there (which can't
be done all that efficiently).
Also bring back the old "allow starts coming from foreground apps"
only for the MODE_IGNORE app op, since it should provide some
better compatibility.
Test: ran them.
Change-Id: Id4ea7f992d12ce4bd8e54f1dbaeb4a460a3dee59
While attaching or detaching a physical keyboard, we should handle the
configuration change in RecentsActivity, so that the activity isn't
relaunched and causes abnormal behaviors.
Test: Checked that while keyboard is attached or detached, Recents
behaves normally.
Bug: 32101881
Change-Id: Ibd185aeb48b31dbde032e235fdcaa17fbcdd9c8a
Adds support to request scores in WifiTracker and then plumb
those scores via AccessPoint.java. AccessPoints will sort on
ranking scores. Show badging in WifiSettings picker.
Bug: 33457699, 33778046
Test: Unit tests
Change-Id: Icc3161cf147b3a9715d6e9f56af574e52ae6c832
This stops us from depending on Settings for keeping the work profile
secure. Instead that is delegated to a smaller Activity inside SystemUI
which has just two jobs:
1) Don't let anyone see the content that's supposed to be locked.
2) Start ConfirmCredentialsActivity (still lives in Settings for now)
Bug: 31001762
Test: //cts/hostsidetests/devicepolicy/src/com/android/cts/devicepolicy/MixedManagedProfileOwnerTest#testResetPasswordFbe
Test: //tests/PoApi/src/com/google/android/afwtest/poapi/WorkChallengeTest
Change-Id: If43820b683007a60a37edf32fb65b442a8fb709b
- Due to jank when finishing the PIP menu activity, we handle the
menu visibility explicitly and keep the menu activity around
once triggered (until PIP ends), instead of finishing and
recreating it each time it is invoked. This also gives us the
flexibility to control how the animation looks of both the menu
and individual actions.
- Allow dragging the PIP while the menu activity is showing and
taking input
- Tapping outside of the PIP now hides the menu
Test: Enable the tap-to-interact in the SysUI tuner and drag while
the menu is showing.
Change-Id: Iac74710100d793e6825b00c7c0d71b85fb420fa0
Signed-off-by: Winson Chung <winsonc@google.com>
This was the first attempt at implementing grid-based Recents.
The new implementation doesn't use a separate activity and reuses a lot
more code.
Bug: 32101881
Test: Checked Recents behavior on local sw600dp device
Change-Id: Ic3535fc49f3f5448d6002d354678b633f122f57d
This only adds an animation when transitioning into recents. "Out"
animations will come later as they need to be run in parallel with
launching the activity not to introduce any latency.
Test: Open recents on sw600dp device, check recents layout/animations
Bug: 32101881
Change-Id: I367f8e5c106cd06d2a7833c165ecb960a7821ed9
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: Tested new activity behavior on local Ryu. Added tests for layout logic.
Bug: 32101881
Merged-In: I550f6e7ea0de3937dbf80e5f0294676cfe567d47
Change-Id: I46a537646e98b312d831510e1d331948888ae5ce
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.
