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)
- 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)
This is best effort change and not perfect (not even close), but works for one game,
and hopes it can handle many other apps that uses set/get Matrix. If you have an alternative idea, please let me know.
use by SearchDialog. SearchDialog wants to be able to say a dropdown should
not always be visible but still let it ignore outside touch when it does
show.
Fixes http://b/1997170
* changes:
* Revert the change that I introduced while refactroing in SurfaceView#dispatchTouchEvent * Don't scale back the event if the canvas is used in SurfaceView.
Before, if a column contained null, MatrixCursor.getString()
returned the string "null", and the get<Number>() methods
threw exceptions.
Now, getString() returns null, and get<Number>() return 0.
Fixes http://b/issue?id=1996628
Instead of a list, we now just have a single boolean indicating whether an
application is density aware, and this set set to true by default as of
Donut.
* changes:
Resetting the setLanguage() call to its intended behavior after change 8089 which works around the bug where a language cannot be set if the default language (which is loaded upon initialization) isn't eng-USA.
* changes:
Always call ensureImeVisible when the text field is clicked. We want this regardless of whether dropDownAlwaysVisible is true or not, as long as the popup is showing and is potentially obscuring the IME.
Sometimes when searching, some of the suggestions had no left padding.
The left-hand side icons were flush with the left edge of the screen.
The problems was that setting a StateListDrawable as a background
will always set the padding of a View, because of a problem in
DrawableContainer.
DrawableContainer.DrawableContainerState.getConstantPadding()
will always return a Rect if mVariablePadding is false, which
makes DrawableContainer.getPadding() return true, which
causes View to change the padding.
As a workaround, we use setVariablePadding(true) on the background
that we create.
Fixes http://b/editIssue?id=1984813
This way someone can call searchManger.startSearch() and immediately have searchManger.isVisible() reflect
the correct value.
Fixes failing tests and bug 1993675
Before, SQLiteDatabase.updateWithOnConflict() method generated
syntactically invalid SQL if the ConflictAlgorithm was non-null.
For example, it would generate
"UPDATE OR REPLACEshortcuts SET ...",
when it should be "UPDATE OR REPLACE shortcuts SET ...".
Fixes http://b/issue?id=1995470
This changes the names of the directories in aapt, to what you see
in the list of DpiTest resources. Also adds a new "long" configuration
for wide screens, which the platform sets appropriate, and introduces
a new kind of resizeability for not large but significantly larger
than normal screens which may have compatibility issues.
the search manager at that point.
Still works:
- hitting search when a managed dialog of an app is showing will dismiss
the dialog and start in-app search (if it supports it), falling back
on global search
- hitting search when a dialog of an app (not managed by the activity) will
dismiss the dialog and start global search
- hitting search when a system dialog is showing will just dismiss the dialog.
