Since the search UI is handled by the system process, and
the service calls to show and hide it are asynchronous,
the tests that checked the visibility of the search UI were
very flaky. This change sclaes the tests back to just check
that nothing crashes when showing and hiding the search UI.
Fixes http://b/issue?id=1993675
Merge commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8'
* commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8':
Allow for screen density drawables in compatibility mode.
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.
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
Merge commit '11b822d2a91ea17c34c0cb1c11e80a9a30d72864'
* commit '11b822d2a91ea17c34c0cb1c11e80a9a30d72864':
Simplify density compatibility to a boolean.
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.
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.
Merge commit '5c536e9162721c460699a041959a0d67de1d20db'
* commit '5c536e9162721c460699a041959a0d67de1d20db':
Fix issue where scaled bitmap sizes could be wrong.
Merge commit '22eef5da75604cd14c0f87332cf957c9948a6e33'
* commit '22eef5da75604cd14c0f87332cf957c9948a6e33':
Add a delay before collecting memory information
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.
Hopefully this gives enough time for more memory recycling. Because it is observed that several seconds after a suite is run, the memory usage could drop by 1-2M.
Move VCard code from android/syncml/pim to android/pim since the code is not
related to SyncML at all; Previous code was misplaced, I suppose.
Reorganize "Builder" structure:
Create VCardBuilderBase.java as a base class for "Builder" classes.
Separate VCardDataBuilder to several components.
Now, VCardBuilder is able to accept EntryHandlers (interface) which handle each VCard entry.
Add EntriCommitter and ProgressShower as ones of EntryHandler implementations.
Stop using VNode/PropertyNode in the actual importing path. Instead, VCard importer directly
creates ContactStruct object.
PropertyNode is still used in test codes, since it does not drop any kind of information
while ContactStruct does.
All codes are made hidden (with package.html) like the files in syncml directory;
These files are only for Contacts app.
Issue
- due to internal issue 1975498, any performance test cannot be conducted.
Next todos
- Add tests for ContactStruct.
- remove android/syncml directory.
- Rename several methods; old names are based on V??? structure, which does not make sense in the current code.
- Use ContentProviderOperation instead of relying on beginTransaction()/endTransaction().
- Use ContactsContact in Eclair
Related internal issues
- 1784580, 1728351
