to the left of the search field. Also, because this removes context
about whether you're in browser search or global search, we make
sure to clear any entered text if you jump out to global search from
within browser search.
This is a really ugly hack, but was required by the UI team. We will
find a better way to reconcile in Eclair.
This will fix a CNAP-related bug where missing a call from a party with an
"Unknown" number presentation and then trying to log that call will cause
a NullPointerException to be thrown.
This was already merged into master so marked will not be merged.
Removed the TTS_ prefix in the TextToSpeech class to follow the standard naming convention.
Moved the TTS-related intents from the Intent class to TextToSpeech and TextToSpeech.Engine.
Renamed the TextToSpeech.Engine constants that are used as extras for the
ACTION_TTS_CHECK_TTS_DATA intent to prefix them with EXTRA_.
Cleaned up the other TextToSpeech.Engine constant to remove superfluous mentions of
"TTS" in the name.
Re-arrange various things to ensure that the search dialog is told about system windows being
closed before it is told about the navigation back to home.
As described in http://b/issue?id=2017825
PopupWindow.getMaxAvailableHeight() does not include the padding in
the available height. To get the ACTV drop-down to actually fill
the screen, this change adds the padding to the value returned
by PopupWindow.getMaxAvailableHeight().
This is part of the fix for http://b/issue?id=2014450
RL was applying a horizontal offset to its children even when the gravity was only
specified for the vertical axis (and vice-versa.)
Also fix the ExpandableListView icons.
* changes:
Fix resource code and version attributes Create a new package setting object for updated system apps rather than moving around the same setting. This updates the resource, code and version correctly. For updating system packages, disable the package first which removes the entry from internal structures, create a new package setting, add it to list of user id's then rest of installation steps, kill the process if needed via ActivityManager then add this setting if everything was successful. This also fixes issues with updating values prematurely.
Create a new package setting object for updated system apps rather than moving
around the same setting. This updates the resource, code and version correctly.
For updating system packages, disable the package first which removes the entry
from internal structures, create a new package setting, add it to list of user id's
then rest of installation steps, kill the process if needed via ActivityManager
then add this setting if everything was successful. This also fixes issues with
updating values prematurely.
When a new version of system package is available via OTA, just physically remove
entries for pkg. Note that the component and other info will be eventually updated
later on when scanning the package.
Also move certificate verification slightly ahead before scanning packages.
Some null checks
New api's in ActivityManager to kill an application pkg before finishing installation
This adds a hidden method AutoCompleteTextView.isImeHidden(),
and uses that in SearchDialog to cancel the search dialog
when BACK is pressed, if there is no previous search component
to return to.
mlebeau says:
If we fill the whole screen then it makes the issue of the back
button a little more important. Specifically, right now if you have
the list expanded and you press back, the keyboard hides but it's not
really showing any more anyway so it seems like pressing the button
does nothing. We rationalized this by saying "part of the keyboard
will be showing so it won't be completely non-obvious that it was
hidden". But since really the right UX is to fill the screen, as part
of this we should probably also add logic to the back button such
that if it is pressed when the list is obscuring the keyboard
(i.e. softInputMode on the PopupWindow is INPUT_METHOD_NOT_NEEDED)
then we should hide the dialog entirely rather than closing the
keyboard.
This is part of the fix for http://b/issue?id=2014450
We now distinguish between in-app search (pivoted in from GlobalSearch)
and real in-app search mode. Only the latter dismisses the search
dialog when a suggestion is clicked. Also, the drop-down
is now always visible except in real in-app search mode.
Fixes http://b/issue?id=2014626
* AccessibilityService -- document onBind() to not be implemented.
* GestureLibrary.getLearner() -- needs to be hidden.
* IntentSender -- remove protected constructors, document that it is retrieved from a PendingIntent.
* Hide permissions: SHUTDOWN, STOP_APP_SWITCHES.
* Context -- hide BACKUP_SERVICE.
* ContextWrapper -- hide getSharedPrefs bla h blah
* Intent.parseUri() -- fix docs.
* ApplicationInfo.FLAG_TEST_ONLY?!?
* Hide MockContext.getSharedPrefs blah blah
When we made the bookmark permissions public, we also changed their
names, which might break existing apps. Change them back. Depends
on a change in packages/apps/Browser
An issue with the density API is that bitmaps assumed the old default density,
so new programs would have to explicitly set the correct density for every bitmap
they create.
This is an attempt to fix that situation, by define the default density of bitmaps
to be the main screen's density, except for old apps where it is the original default
density.
Actually implementing this is not so great, though, because the Bitmap constructors
can't really know anything about who is calling them to know which density to use.
So at this level the compatibility mode is defined per-process -- meaning the initial
package loaded into a process defines the default bitmap density, and everyone else
loaded in later on has to live with that.
In practice this shouldn't be much of a problem, there shouldn't be much mixing of
old vs. new apps in a process. It does mean that, going forward, if a developer is
going to use shared user IDs for this, they will need to make sure either that all of
their apps are in the same compatibility mode, or that their code explicitly sets the
density of bitmaps it receives. This isn't all that great, but I think it is worth
the benefit of allowing people who write modern apps to not have to deal with bitmap
densities.
This change also does some cleanup of the density management (making sure to always
copy over bitmap densities, etc) and adds java docs to explain the various ways
density is set and used by the system.
This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.
This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).
As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
In some locales, there are no abbreviated month names; the abbreviated
date formats are essentially numeric. If the user is in such a locale,
have the DatePicker respect the date format setting so that the order
of the fields will match other numeric-only dates.
In locales that have abbreviated month names, continue to use the order
that is normal in spelled-out dates.
And update the order in updateDate() so that the new order is reflected
if you change the order setting and immediately go to change the date
without leaving and returning to the Date & Time settings in between.
At the same time, change DateFormat.getDateFormatOrder() back to working
the way it did in cupcake (prioritizing the date order preference over
the locale), even though the DatePicker no longer calls the method.
Bug 1805085
by surface flinger in compatiblity mode. The original approach confused the app because
the surface size and the view size were different.
* a few clean up. removed unsed arguments, obsolete conditions from getTranslator()
(expandable check was a bug)
* changes:
* a best effort fix for apps that uses get/set Matrix API on canvas. - scale the matrix - but don't scale if the matrix *looks* like obtained from the canvas itself. (typically to set it back to original matrix)
