Don't start work challenge unless auto-cancel.
This bit of logic ensures that the notification from a work app doesn't get cancelled prematurely when the user taps on it and then dismisses the work challenge window. If an activity is started for a locked profile user, work challenge will be started by the ActivityStartInterceptor logic anyway, so this logic doesn't add much value if the notification doesn't auto cancel on click. This CL allows intents leading to showWhenLocked activities to be invoked by tapping on a notification, like an incoming call notification from the dialer. Bug: 279147687 Test: manual with incoming call Change-Id: I2e5f3bfab31e3ebc1d1e2713f86570ff5ee0420a
This commit is contained in:
@@ -304,10 +304,11 @@ class StatusBarNotificationActivityStarter implements NotificationActivityStarte
|
||||
ActivityManager.getService().resumeAppSwitches();
|
||||
} catch (RemoteException e) {
|
||||
}
|
||||
// If we are launching a work activity and require to launch
|
||||
// separate work challenge, we defer the activity action and cancel
|
||||
// notification until work challenge is unlocked.
|
||||
if (isActivityIntent) {
|
||||
// If the notification should be cancelled on click and we are launching a work activity in
|
||||
// a locked profile with separate challenge, we defer the activity action and cancelling of
|
||||
// the notification until work challenge is unlocked. If the notification shouldn't be
|
||||
// cancelled, the work challenge will be shown by ActivityManager if necessary anyway.
|
||||
if (isActivityIntent && shouldAutoCancel(entry.getSbn())) {
|
||||
final int userId = intent.getCreatorUserHandle().getIdentifier();
|
||||
if (mLockPatternUtils.isSeparateProfileChallengeEnabled(userId)
|
||||
&& mKeyguardManager.isDeviceLocked(userId)) {
|
||||
|
||||
Reference in New Issue
Block a user