Merge commit '841f13c8e9ff3f7695b6c18a8abcec3c947983ff'
* commit '841f13c8e9ff3f7695b6c18a8abcec3c947983ff':
* Reverted the change in PackageParser that I checked by accident
Merge commit '5c536e9162721c460699a041959a0d67de1d20db'
* commit '5c536e9162721c460699a041959a0d67de1d20db':
Fix issue where scaled bitmap sizes could be wrong.
* More surface view fix.
- correct event translation on surface view.
- use compatible window
* removed FLAG_NO_COMPATIBILITY_SCALE. It was my misunderstanding of how SurfaceView works, and this was not necessary.
* Added compatibility related info to package dumpsys
The Bitmap functions to get the scaled width/height couldn't actually
do the right thing because they didn't know the destination they would
be drawing to. Now there are two forms of them, taking an explicit
parameter specifying the destination.
Merge commit '54f09101381fa63dca35ae4ea0ba3802ee863236'
* commit '54f09101381fa63dca35ae4ea0ba3802ee863236':
* Use Fede In/Out animation if one of opening/closing apps is in compatibility mode.
* changes:
* Use Fede In/Out animation if one of opening/closing apps is in compatibility mode. * preserve compatibility window flag when the app updates window's layout params. * Added assertion in DEFAULT_COMPATIBILITY_INFO object to prevent unintentional modification. * A few minor updates * log/dump message improvement * Removed unnecessary method in FadeInOutAnimator * Fixed 100 char issue in WindwoManagerServer.java
* preserve compatibility window flag when the app updates window's layout params.
* Added assertion in DEFAULT_COMPATIBILITY_INFO object to prevent unintentional modification.
* A few minor updates
* log/dump message improvement
* Removed unnecessary method in FadeInOutAnimator
* Fixed 100 char issue in WindwoManagerServer.java
* commit 'goog/readonly-korg-master':
Fixed Android issue #400, where the Intent documentation was inaccurate in a number of places, undoubtedly causing untold grief to innumerable masses.
Bug Fixed for libagl.
Merge commit '83a066c6d8ed953c3f5a1a44316509c9a9b0c6c2'
* commit '83a066c6d8ed953c3f5a1a44316509c9a9b0c6c2':
Fixes lock on Home. Adds a new API on Dialog to get a callback when the dialog
This adds a new API with the activity manager to find out about movement between
activities. For my sanity, the old IActivityWatcher is now renamed to
IActivityController, and the new activity movement interface is named
IActivityWatcher.
This changes the search manager itself to use the new API to manage its state.
Note that there are still problems when going back to the search dialog after
it was hidden -- the suggestions window no longer appears until you explicitly
dismiss and re-show it.
Currently, ASCP calls onAccountsChanged with an array of ALL accounts, but
ContactsProvider and CalendarProvider assume these are all GAIA accounts.
This can cause a looping crash in acore, so the code has been changed to
only pass an array of GAIA accounts...
This is the problem where various things are listening for broadcasts
(such as battery status, PIN/PUK/Network) that an application can send
to cause harm to the system.
Solving this is tricky because many of these broadcasts are sticky,
and I have never figured out how to do permissions with sticky
broadcasts in a sane way. So instead, I am going to punt on the
general problem and just brute force it:
There is new a way for system components to declare specific
broadcast actions to be protected, which means that only the system
and the phone can send them. This is good enough for now. None
of it is exposed in the public API so we can make something a little
less stupid in the future if we ever need to.
This adds a new <path-permission> tag you can use inside of a <provide>
to define additional path-based permissions that broaden the global
read and write permissions. The initial use for this will be global
search, so that a content provider that is protected by permissions
can make a part of itself available to global search under another
permission. This addresses the issue with global search not being able
to request permissions it would need of providers it doesn't know
about at build time.
Merge commit '1ecf5d28817f0a051e77488380dcd5bc622ea169'
* commit '1ecf5d28817f0a051e77488380dcd5bc622ea169':
Re-implementation of large screen support using window manager.
* added background filler surface to fill the outer rim. Using the same layer as dim surface because
they never co-exists (in the same window)
* clean up the obsolete code in CompatibiltyMode/ViewRoot for support large screen support.
Merge commit '569076c9f6bdadb4d3285a26e069634a839b5b87'
* commit '569076c9f6bdadb4d3285a26e069634a839b5b87':
widgets scaling fix. Use container's compatibility info and display metrics when container and widgets disagree.
A restricted Context is a special type of Context that prevents specific features
from being used. For instance, android:onClick, used by View, can be dangerous when
used from within apps widgets. By using a restricted Context to inflate apps widgets,
widgets providers are prevented from using android:onClick.
Merge commit 'd7cd29da91ccc0aba1f1097e19366f9ca36c7ce1'
* commit 'd7cd29da91ccc0aba1f1097e19366f9ca36c7ce1':
Add facility to run setup wizard after an update.
The system now keeps a tag of the last version (just an arbitrary string)
that the setup wizard was run for. If this is different than the current
one in the setup wizard, then setup is launched at boot.
This introduces a new intent action for the part of the setup wizard that
gets run for an ungrade, which the system uses to find its current version
tag for comparing against what was last stored. It is up to the launched
setup activity update the stored setting to reflect its current value,
once it is happy.
This is a little hacky -- we just assume that if adb is enabled and power
is connected through usb, then it is active.
The icons and text are temporary until final design is provided.
Merge commit '72eb0acad5cffc57ce5006f6deab29ee259e461e'
* commit '72eb0acad5cffc57ce5006f6deab29ee259e461e':
Expand support for different screen sizes.
Applications can now declare that they support small, normal, or
large screens. Resource selection can also be done based on these
sizes. By default, pre-Donut apps are false for small and large,
and Donut or later apps are assumed to support all sizes. In either
case they can use <supports-screens> in their manifest to declare
what they actually support.
