We were leaking the first WebView created since we kept a reference
in a static variable. Using the new way of sending messages in a
static method to avoid this.
Change-Id: Ibb665e32c22c16c17176cd69bf8f7e83fd94894f
in HC, using DownloadManager public API, download directories
named by the constants Environment.DOWNLOAD_*
may ot exist. theyneed to be created or
the download request should fail ASAP.
bug:3297328
Change-Id: Ic87023d8fe98bd240744f66607a5400b7825e17e
To make a 800 tall screen run like a 720:
adb shell setprop persist.demo.screensizehack 800=720
Note this is a persistent property, so it will (intentionally) remain across boots.
Change-Id: I8a8a9f937399327444e8fb154b91f0e642db116e
Do not rely on standard word detection for these (which does not work because
of / or . in URL or - in phone numbers).
Various other bug fixes for text selection with autolinks.
Change-Id: I482e99efa980281086ce761b27b3a36579e7cf76
Refactor for canSelectText.
Moved test from onCreate to startTextSelection.
Restored setFocusableInTouchMode needed to start a selection in touch mode.
Bug 3296490
Change-Id: I5c0c31dbebed79fd1f9d80f930cba1019d74f710
This class gives fairly low-level access to the HTTP cache, which
as far as we can tell was only exposed for the benefit of Gears.
BUG=3270236
Change-Id: Ibce10ecf8b524d3f472affa2a37fe4de15efd2ed
The problem was that NumberPicker override View.draw(), but did not
call the superclass version of the method in some situations. This
resulted in the DIRTY flag for the view not getting cleared properly,
and future invalidations not propagating correctly.
The fix was to call super.draw() from NumberPicker.draw().
Change-Id: Ic17215dea86d54b77375494ada124dd6970e3ad6
This is needed to construct a cachable CacheResult object.
Currently only WebViewWorker is able to do this, by updating
the fields directly.
Bug: 3270236
Change-Id: I50148697dcee4d329e1436a2ce4c15224cb5ae30
list UI is not ready yet
This involves some reworking of Loaders.
Loaders, in particular CursorLoader, are now expected to retain
their current data after being stopped. This allows applications
to keep that data across onStop() -> onStart(), so when the user
returns to the app it doesn't have to wait for the data to reload
and thus cause flicker.
This includes various API changes to better reflect the new
semantics, plus a new LoaderCallbacks method to tell the application
when it is actually time to stop their use of a loader's data.
Note this is somewhat half-done, to help checking in the extensive
application changes that are required without causing build breakage.
Change-Id: Ib4b3bf8185a6da46e7f06ca125521d65e2e380a1
