When the clear top and reset task launch flags are specified for a
standard launch mode activity, we should not add the activity to the
task before taking these actions. Doing so leads to the potential of
prematurely ending the starting activity and reparenting the activity
without a window container controller set.
This changelist ensures that the task is not associated until later.
Fixes: 70635977
Test: atest CtsActivityManagerDeviceTestCases:ActivityStarterTests
Change-Id: I8e2245f9ad9f07e259b099daefe9ebb2170ae28d
The existing name is misleading, because it can be read as requiring
that a trusted user be present, rather than the intended meaning of
requiring trusted proof of user presence. Since this is all about
TEE/SE-based keys, the "trusted" part is implied, so the simple
"userPresenceRequired" name makes more sense.
Bug: 77151288
Test: Keystore CTS tests
Change-Id: If8b533b9f34a1875eaf35cdd1bb8f3709da9761b
When a Dialog's show() method is called, it makes a copy (l) of its window param
and change the copy's softInputMode before calling wm.addView(). This call ends
up calling WindowManagerGlobal.addView(view, l, display, parentWindow),
which in turn sets the application token from the parentWindow into l and stores
l on its mParams map.
Later, when the dialog layout is changed (for example, if it's resized), the
original params ends up passed to WindowManagerGlobal.updateViewLayout(),
which in turn updates it's internal mParams with it, hence losing the
application token (as the token was set in the copy).
Then, when Autofill (and possibly Assist) is triggered to that activity, the
Dialog's view hierarchy is ignored because WindowManagerGlobal.getRootViews()
ignores views whose params do not have an application token.
This CL fixes this issue by passing the original dialog's param to the wm
method and resetting the softInputMode that was changed, rather than making a
copy.
Test: atest DialogLauncherActivityTest
Test: manual verification with Twitch
Fixes: 68816440
Change-Id: I55f510ab7a44030bc368221b7db1a221bc2e09c8
The current calculation includes data usage for the current day,
which causes the returned daily quota to change during the day.
This makes it difficult to use for callers that need a fixed
data limit for the day.
Current usage in MultipathPolicyTracker (the only caller) is
incorrect because of this, as it assumes that quota is not constantly
changing.
Test: Tests in go/ag/3803612 pass
Bug: b/72631572
Bug: b/72877610
Change-Id: I9b3edde2dee7c7479d428e2bf2b73297afed3e6b
The fail is related to a recent fix to PermissionMonitor
that went into pi-dev only : ag/3799094, which fixed getting
the remote package name for the correct macro user instead of
the default. That fix had broken the test, this change fixes it.
Test: test now passes
Bug: 77315205
Change-Id: I26f8276eafe80478d5fefcff92e7dc2f12128bb4
