* changes:
Add a new feature to android.os.Debug to add the ability to inject only specific fields when calling setFieldsOn().
Fixes#1836075. Adds consistency checks for the View hierarchy. To enable them, you need a debug build and ViewDebug.sConsistencyCheckEnabled set to true in debug.prop. This change also lets you easily enable drawing and layout profiling in ViewRoot by setting ViewRoot.sProfileDrawing, ViewRoot.sProfileLayout and ViewRoot.sShowFps in debug.prop with a debug build.
* changes:
Make pressing the search button within an app that does not support search bring up global search. This still respects the case where an app has chosen to disable search entirely by overriding onSearchRequested() to return false.
Fix a bug where the filter text could not be deleted,
and another where filtering changes the checked item,
so that filtering <select> lists can be reenabled.
* changes:
Density Compatibility mode for SurfaceView * use fixed size when requested. Otherwise, give the original size instead of scaled down size. * scale back the motion event to original size when surface view is using the orignal size.
* use fixed size when requested. Otherwise, give the original size instead of scaled down size.
* scale back the motion event to original size when surface view is using the orignal size.
You can now use android:testOnly="true" to not allow your .apk to be installed
as a normal app. The only way to do so is with the pm command and giving the
-t option, which sets a new INSTALL_ALLOW_TEST flag when installing.
I also used this to clean up the install API... actually, mostly to hide
it, since it is not accessible to apps so shouldn't be in the SDK. We
will be doing some more work on it, so this will prevent adding yet
another backwards-compatibility-for-no-reason version.
search bring up global search. This still respects the case where an
app has chosen to disable search entirely by overriding
onSearchRequested() to return false.
I do not believe any changes to the SearchManager documentation
(http://developer.android.com/reference/android/app/SearchManager.html#HowSearchIsInvoked)
are necessary, because this documentation already indicates that
pressing the search button within an app that does nothing special with
regard to search can bring up global search.
* changes:
Check the size of the data to write for STATIC AudioTrack objects. Extracted actual writing from write jni function so it can be reused in an upcoming change.
* changes:
Fixes 1844680. Interrupted scrolling could lead to rendering artifacts. The ListView was invalidating itself in opaque mode but before the drawing could happen, it was getting rid of its scrolling cache, thus becoming translucent again.
* changes:
Fixes#1846038. DrawableContainer was wrongly returning its opacity by ignoring the visibility of the currently selected layer. This change simply reports a TRANSPARENT opacity if there is no currently selected layer of if the selected layer is not visible. Otherwise it reports the opacity computed by the state class.
* changes:
* update all metrics data when updating density. * Keyboard should use DisplayMetrics from Resource rather than getting it from WindowManager as the display metrics can differ under compatibility mode.
* Keyboard should use DisplayMetrics from Resource rather than getting it from WindowManager as
the display metrics can differ under compatibility mode.
* changes:
Fixes#1596240. Optimize invalidate/draw passes by marking opaque views and avoiding drawing them. Whenever a View requests an invalidate its parent check whether the view is opaque or not. When the view is not opaque, the framework behaves as it used to. However, when a view is opaque, the parent marks itself as being dirty because of an opaque view. Its parent then does the same, and so on. When the framework then starts drawing the views, it does not draw views marked as dirty opaque. If a view is dirty opaque and receives an invalidate request from a non-opaque view, it then clears the dirty opaque flag and behaves as before.
Issue 1837610 Adding a Widget before Running the Associated App Causes a Force Close
We were not retrieving the shared libraries of an application when deliving a
broadcast to an explicit component.
Issue 1753079 loading class path of instrumented app into instrumentation may load wrong path when instrumented app shares process with other apps:
We were using the ApplicationInfo that was used to originally create the process, not the one that the
instrumentation is against.
