These are no-ops since WebView 95; remove them from the SDK to make it
clear to apps that they're nonfunctional.
Bug: 199287927
Test: atest CtsWebkitTestCases
Change-Id: I498aff6f8a0c2901504d777f597dbf77f982cd3a
`filename` must be `null` at this point, as it's recently been set to that value, and hasn't adopted any other value yet.
Refactoring change only. No functional changes intended.
Change-Id: I29a28872efc8c12c0da3c9f7c0a92d6aff465410
This reverts commit cb5a80ea57.
Reason for revert: Was not the cause of the test failure
Fixes: 186622527
Test: atest FrameworksCoreTests:ContextTest
Change-Id: I705854f080200f0465d94a7754e710f05a3ec92c
The current 130MiB is not sufficient for the latest Chrome x86 dev build
of stripped native library. Official ARM library is around 59 MiB (on
disk). This flavor is slower to build and is less convenient to test
with.
Keep the 32bit arm reservation size unchanged, it is sufficient and
allows growth.
Bug: 184808875
Test: Manual: start a "release" build of Chrome/x86 (but not
"official"), observe that with the change Chrome can
mmap(MAP_FIXED) all the segments of the native library into the
region successfully
Change-Id: I00507169eafbdcfc4d413bb9c76188e179ca0c0e
If an application caches an ApplicationInfo and uses it to call
Context#createApplicationContext, the app will not get the most recent
version of the overlays for that application. To make things worse, the
LoadedApk stored in ActivityThread#mResourcePackages is updated using
the old ApplicationInfo causing further uses of the cached LoadedApk to
return outdated information.
Deprecate Context#createApplicationContext, convert all internal uses
to Context#createPackageContext(String packageName, ...) and log
whenever any one calls Context#createApplicationContext with an
outdated ApplicationInfo to detect debug issues in using old infos.
Bug: 188059515
Test: change wallpaper and observe widgets get reloaded with most
recent overlays
Change-Id: I2aeefa8c0e66264859109975a54c4f73f76ad710
Rework the new WebView startup timestamp system API to use a class with
named getters instead of an array with an @IntDef index.
Fixes: 184026615
CTS-Coverage-Bug: 183239482
Test: n/a
Change-Id: I22c95b1c2dc98f8ecd23ce22dc21e3d0158d9e1b
This change doesn't introduce a new API, the change is just pushing
down an existing API from View that we are missing to add for the
webview. We should also provide this method to allow webview provider
to provide their implementation if needed.
Bug: 186617107
Test: manual
CTS-Coverage-Bug: 177960696
Change-Id: If75285b3aafdb1f2a3d7c307a90bb783edf029b5
Explaining when the method will return null and how that is
handled.
Bug: 180991400
Test: No logic change, current tests should pass.
Change-Id: Iae0a383cf173b80f50ea2bba46a3d263bed8f512
We should use uptimeMillis for the startup timestamps since it doesn't
count time in device sleep.
Fixes: 184786485
Test: n/a
Change-Id: I4073e73de9b76d50398b820879c4fcf7b8f614e8
Specify that the values are @ElapsedRealtimeLong and document the
entries in the array via the index constants.
Fixes: 184786485
Bug: 184026615
Test: n/a
Change-Id: I26e3df80e79b14d2301e28da93f7814bc67bdb6a
1. We provide virtual child list to View#onCreateTranslationRequests
but we don't provide a method to allow developers to create
ViewTranslationRequest for virtual AutofillId. Add a builder
constructor to allow developer to use it for virtual AutofillId.
2. Fix some comments in ag/13982294(e1b23cd)
Bug: 177789967
Test: manual on sample app
Test: atest CtsTranslationTestCases
Change-Id: I63e914b888b23cdb7a5169fc6931be93625ca8e4
ag/13435848 introduces timestamp collections based on
System.currentTimeMillis but elapsedRealtime is a better
choice for a interval timing.
Bug: 180489435
Test: n/a
Change-Id: If7b29cbe90e8bba76bccb42a5bc570c08b75c9e7
No change to logic, only documentation change. This adds some
clarifications to getCookie()/setCookie():
* getCookie() returns multiple cookies, setCookie() accepts only one
* This briefly describes getCookie()'s output format because it's fairly
simple
* This summarizes setCookie()'s input format and provides an example,
but directs the reader to the RFC spec for a full description
* Minor formatting changes, including editing a javadoc link which
doesn't currently render correctly in kotlin docs (for
ValueCallback#onReceiveValue)
Fixes: 175471135
Test: m offline-sdk-docs -j4
Change-Id: Id9052fa03584caae5ffc92ed1f6c4d2641d900ce
This change records timestamps that happen before the WebView APK's code
is loaded and can record timestamps itself.
Bug: 177895749
Test: n/a
Change-Id: Ibb832fa13e868846625cc02c584a535a11561c66
We were catching and ignoring exceptions when looking up the provider
factory method, because in the past the code fell back to calling the
provider constructor instead. However, this case was removed a while
ago, so now if the reflection fails the exception will be lost.
This isn't a big issue as it will still crash with a
NullPointerException when trying to call the method that wasn't found,
but it makes the cause of the problem less clear. Remove the extra
try-catch and just handle all exceptions thrown during the process of
creating the provider the same way.
Test: atest CtsWebkitTestCases
Change-Id: Ib2079e743a830a04a4117d782afa6eaaa26766df
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Merged-In: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
This reverts commit 039e10f76a.
New WebView binary has now been dropped, fixing the strict mode issue that necessitated a revert.
Change-Id: I86644e8a216c7087d7a00294d2b7f9ddb1705968
This reverts commit cfa9b7033c.
Reason for revert: WebView M85+ has a strictmode violation
Bug: 169877920
Change-Id: I46a26c16d83debc548217538200c6736ab8abeae
No change to logic, only docs. Updates loadUrl documentation to make it
clear that some WebView versions require the Map parameter to be
mutable.
Bug: 145881245
Test: m offline-sdk-docs -j4
Change-Id: I15f3c48f02090b8855880ff5d39c02aa28d4dfa8
