The history picture and the layers drawn may be out of sync,
so for now, don't draw the layers when the history picture is
drawn.
Also, remove native class check from drawExtras() since it
is already checked by the caller.
fixes http://b/2457350
fixes http://b/2453780
This is the framework part, moving classes around so the framework
no longer needs to link to android-common. Makes some APIs public,
others that didn't need to be public are private in the framework,
some small things are copied.
When LinearLayout is measured in EXACTLY mode, we handle the negative margins
a bit differently. This is to support the use case of the current tab design.
Drawing elements that appear atop or below layers need to be
drawn both in the proper order and with the correct canvas to
respect clipping and the matrix.
The logic of what to draw is still in WebView.java, but the
actual drawing calls are now triggered inside the layer code.
This still draws layers incorrectly after drawing the history;
will fix this in a future CL.
Move drawing to WebView.cpp.
Use inverseScale to simplify viewPort metrics.
Remove root layer; let WebView.cpp handle it exclusively.
Requires companion fix in external/webkit.
http://b/2457316http://b/2454127http://b/2454149
MountService updates state on PackageManager and then tries to
kill processes holding file references to media about to be unmounted by
invoking api on ACtivityManager. This is retried upto 4 times to make sure all
processes holding file references are killed before unmounting the media
at specified path.
Also changed PackageManger api to return boolean value to indicate if
MountService is likely to receive broadcasts related to apps on sd.
There were three main complains about orientation sensing:
* Switching to landscape when putting a device down on a table (or picking it up)
* Changing orientation due to road bumps or vehicle vibrations while in a car dock
* Switching to upside-down too easily
This change includes three primary enhancements.
First, we run the accelerometer output through a lowpass filter before considering its orientation. This avoids glitches due to brief phone movement, particularly when the phone hits a table. The filter uses a very low default time constant of 200ms to retain responsiveness (note the samping period is ~200ms, so the effect of this filtering is pretty mild). At tilt angles beyond 45 degrees, however, we increase the time constant to 600ms, which helps greatly with avoiding glitches picking the phone up from a table. It does introduce some sluggishness when rotating while the phone is tilted back, i.e. being used in one's lap.
It's also worth mentioning that the accelerometer output on Sapphire appears to be pre-lowpass-filtered with a time constant of around 500ms, making this less necessary on that device, but the added effect doesn't noticeably degrade user experience in my opinion.
Second, we check the magnitude of the raw accelerometer output. If it deviates from the strength of gravity by more than one m/s^2, we distrust the data, since that implies the device is under external acceleration and the sensor data doesn't accurately reflect orientation. This helps avoid glitches due to shocks and vibrations, as in the car dock scenario. However, rather than ignore the data entirely, we filter it with a very high time constant (5 sec). As a result, if the device is rotated while vibrating, even if we never pick up a clean sample, we will eventually detect the orientation switch. Of course, with a sampling period of 200ms, we're prone to aliasing, but that seems like a highly unlikely corner case.
Third, we restrict transitions to upside-down orientation to a much narrower range, both in terms of orientation and tilt. This should prevent upside-down mode from activating in most cases where it's not desired.
I also updated a lot of stale documentation, added a lot of documentation, and cleaned up a lot of the code, so as to make this (often subtle) code as transparent as possible.
If a backup-participating app sets android:restoreAnyVersion="true" in its
manifest <application> tag, then its agent will be invoked for restore
even if the available dataset was created by a later version of the app
than is currently installed on the device. This will not typically be
a problem for third party applications, since for them the installation
and initial data restore are tightly coupled, but it can cause serious
problems for applications which are both preinstalled on the system
partition and overridden by later updates. The primary difficulty
that this new attribute addresses is this:
1. User buys a Nexus One, Market self-updates, and the user installs some apps.
At this point the backup data on the server may indicate that the version of
Market which originated its bookkeeping is newer than the stock N1 Market app.
2. User loses their phone, and buys a replacement N1. At setup time, Market
has not yet had a chance to self-update, so when the restore comes in, it's
tagged as being from "the future" and so the restore is refused. No apps get
reinstalled.
Bug: 2442127
Change-Id: I076a9553dc613e5c3189350e778315718ed1ed2b
Bug #2464502
This fix introduce a new dispatch mechanism to tell views when they are temporary
detached/reattached from/to a ListView. This is very important to remove pending
callbacks or cleanup temporary states.
This change also modifies TextView which was relying on that callback in a very
particular case: a focused EditText in a ListView. The modified code acts only
when in that case, not if onStart/FinishTemporaryDetach() is called via
dispatch*() (== recycled views in ListView.)
the pending TOUCH_EVENTS and then send an ACTION_CANCEL
and skip the rest of touch events.
This should address the drag problem Flash plugin has.
Fix http://b/issue?id=245053
Add null checks to a few places to avoid crashes when dumping
debug data.
Also add some sanity checks for accessing content providers in
the activity manager.
