Adds support for a new AppOp to permit services to
use IpSec tunnel mode. The IpSecService now needs
a context so change the service mode to a cached
service rather than a static service.
Bug: 66955045
Test: runtest frameworks-net
Change-Id: I17a4a286225b432c3e15ea1587d946189931b4f4
Add a new capability that may be granted to past signing certificates
after changing to a new signing certificate that will allow applications
to go back to a previous signing certificate. This capability is
intended to not be granted, but may be added later in the event that
a signing certificate change caused undesirable behavior.
Bug: 73927694
Test: PkgInstallSignatureVerificationTest
Change-Id: I7453a2da00e740a55de45e7b144f308a9bc33772
(cherry picked from commit a1d0cf74f9)
A deadlock between the UI and render threads caused by magnifier is
currently making the running app to become not responding. The deadlock
could happen in the following scenario:
1. The UI thread sets a frame callback and asks mRenderer to sync and
draw the current frame. A draw task is enqueued by RenderProxy in the
C++ code
2. The UI thread starts an InternalPopupWindow#destroy() on the UI
thread and acquires mLock
3. mRenderer#destroy() is called on the UI thread, which enqueues a
destroy task in the C++ code. However, this is implemented
synchronously, so the UI thread will wait until the destroy task is
dequeued and executed
4. Since the draw task was enqueued before the destroy task, this will
be executed and the frame callback will be called on the render thread
5. The frame callback tries to acquire mLock. However, this is held by
the UI thread, so the render thread has to wait for it. At the same
time, the UI thread cannot progress either as it is waiting for its
destroy task to execute.
The CL adds a new lock which is used by the UI thread to mark its
intention to #destroy(), such that the render thread will know about
this before trying to acquire mLock and starving.
Bug: 75276625
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Iedf2948350fcf8dd9c819c085b31b7ccaf2db7c5
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
This is from advice from API review.
- make getText() hidden
- make getWidth()/getBounds() public.
Bug: 76448719
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: Ic22a266a932cda60de6d8b37b8bbf5704291b953
Usage stats corrections for 464xlat in NetworkStatsFactory are not applied
to tethered traffic. Add adjustments in NetworkStatsService. After
migrating external callers off NetworkStatsFactory, we will be able to
only apply adjustments in NetworkStatsService and remove stacked
interface tracking from NetworkStatsFactory.
Bug: 72107146
Fixes: 72107146
Test: runtest frameworks-net & manual - checked corrected network usage
Merged-In: Ieb25c41c651499fdd01225ae5ac21d95e3d823f5
Merged-In: I016722f3a0ae2ae0a1d48bfacc4fe07ee3578ef7
(cherry-pick of aosp I5ce450e616b4fddf21f2a491fe5d0c9e9f969bda)
Change-Id: Id41cf22a0f9a63cb1832e9375bfb045861f08e52
Currently the NetworkStatsManager APIs allow applications to
query for their own data usage by UID and tag, but do not allow
applications to query by foreground/background state.
This is causing popular apps to resort to parsing xt_qtaguid
stats files directly. Because this is no longer allowed for apps
targeting P and above, provide replacement functionality.
This API allows apps to query for data usage for a given state,
but not to receive data usage broken down by state. This is
consistent with how the current UID and tag APIs work. It is also
not an undue burden on apps: there are currently only two states
of interest (FOREGROUND and everything else), and even if we add
states in the future, unmodified apps can still obtain total
traffic using STATE_ALL.
Bug: 72977484
Test: New CTS test added in other change in this topic.
Change-Id: Ic8c9194569ffd599b49e4a8197c5c2ea0ec3f7f7
1. Wraps TC queries in Request objects
2. Adds create/destroyTextClassificationSession system APIs
3. Adds the session Ids to system API calls
4. Change setSignature() to setId() on result objects
5. Plumbing to make the API updates work as things currently work
6. Hide Linkify.addLinksAsync APIs
Bug: 74461129
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextSelectionTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextLinksTest
Change-Id: I933ada8b37ef9893331a265e3b4fc08e043f1029
We try to never display in the magnifier content that does not belong to
the magnified view. If the magnified view has one or more scrollable
containers, these have to be considered in order to find out the visible
portion of the view which is not masked by scrollable containers.
The previous logic for computing the visible region was wrong when one
of the containers was a ViewPager, whose getScrollX() returns the scroll
relative to all pages, rather than the currently visible one as the
logic was expecting. This CL replaces the old logic with a
View#getGlobalVisibleRect().
Bug: 74359490
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ib6b63a35436aa691f29c13a0789688f23bfca9f1
is used.
Throw unsupported operation exception when older version of RecoveryController is used.
Bug: 77293264
Test: atest RecoveryControllerHostTest
Change-Id: I0003104a4305444fac0092f4f6929545cf7c9413
Add events for the keyguard being shown and hidden.
Bug: 74404949
Test: atest CtsUsageStatsTestCases:UsageStatsTest\#testInteractiveEvents
Change-Id: I038e03cf4ba80669d7d17c3d66b98ee81050abc8
The user canceled message is different than the other fingerprint errors
since it is caused by the user explicitly tapping on the UI at which
point the dialog will be already dismissing/dismissed. So the error
should be sent immediately to the application.
Test: manual test with FingerprintDialog, modified to show when the
error messages are received
Change-Id: Ia2a3b0a7ac9c8cfcbd6055045a95fc06aa02c61a
Fixes: 77337939
