Merge commit 'd79d1c72991e587294432e80d091e3ae26a0c103' into eclair-plus-aosp
* commit 'd79d1c72991e587294432e80d091e3ae26a0c103':
If ZoomButttonsController detects more than one pointer,
Merge commit '813d2d86789d1c2e705c4d11d052ad649e6bac84' into eclair-plus-aosp
* commit '813d2d86789d1c2e705c4d11d052ad649e6bac84':
Fix for 2292713: Remove workaround that hides SlidingTab widget while internal state is inconsistent.
Make sure the mZoomOverviewWidth is as least as
wide as the current (adjusted) view width.
This should fix the weird state Bart got in with
m.wikipedia.org.
give up the control. This should enable the View behind
it, like WebView, will always get the multi-pointer
events even when ZoomButtonsController is up.
This adds new DevicAdmin, DevicePolicyManager, and DeviceAdminInfo classes.
See the java docs for each on documentation on them. Basically: a DeviceAdmin
is what you derive from to administer a device; DevicePolicyManager is what you
use to apply and check your policy requirements and perform other administration
tasks.
The previous workaround for this race condition prevented glitches by postponing drawing the SlidingTab until the internal state was consistent.
Unfortunately, the InCallScreen seems to trigger this most of the time if the keyboard is open or the last application was in landscape mode.
Instead, we'll handle this separately in lockscreen.
When adjust scale for zoom overview, keep the state
of whether textWrapScale is matching mActualScale.
So if user pinch during loading, we won't reflow.
Fix http://b/issue?id=2370552
If mViewportWidth is 0, it means screen width. If
textwrapWidth is not same as view width, which means
that we are in the state triggered by pinch, always
send textwrapWidth as width to WebKit to keep the
same layout.
Fix http://b/issue?id=2375232
This is an exact clone of the "public" class, so that applications
that access the raw content provider directly (i.e. Browser) can
continue doing so, at the expense of not being buildable with the
SDK.
The Download Provider itself will also use those constants.
Bug: 2245521
Change-Id: I15f8ca8a3b69719cfbf403fc2607aac0d3c2b79a
this is a clone of https://android-git.corp.google.com/g/#change,35174.
if the cache is full to its capacity and if a new statement is to be cached,
one of the entries in the cache is thrown out to make room for the new one.
but the one that is thrown out doesn't get deallocated by SQLiteProgram
because it doesn't know that it should.
fixed this by having SQLiteProgram finalize its sql statement in
releaseReference*() methods, if the statement is not in cache.