* changes:
Wipe data on backend before a backup run Append the date to 3.txt so that we can see if/when backup failures occurred solely from the device/server state Note that these files will probably be deleted from the tree immediately, to be replaced by the ruby versions.
Append the date to 3.txt so that we can see if/when backup failures occurred
solely from the device/server state
Note that these files will probably be deleted from the tree immediately, to
be replaced by the ruby versions.
Merge commit 'ff6585cbb0e5e42adf056b4a074b9f3683b853c1'
* commit 'ff6585cbb0e5e42adf056b4a074b9f3683b853c1':
Remove flaky MonitorTest#testInterrupt from continuous, and attempt to make
Merge commit '7a07f1797684597a3b932aa0b365049d3e7d6ff3'
* commit '7a07f1797684597a3b932aa0b365049d3e7d6ff3':
After each test, the WebView cache should be cleared, otherwise the cache data will pile up.
- Add copyright headers
- Allow the user to pass options (like '-s FOO') to adb
- Restart device adb as root if needed
- Make test_restore to infer a restore set
Merge commit '8c5b3e2fa60e29e45c97bf83b2aa8c6505987f82'
* commit '8c5b3e2fa60e29e45c97bf83b2aa8c6505987f82':
Change browser reliability test to start a new activity for each url
It turns out we were not returning the density for anything retrieved from a
TypedArray... which basically means any bitmap references from a layout or style...!!!
This is now fixed.
Also fiddle with the density compatibility mode to turn on smoothing in certain situations,
helping the look of things when they need to scale and we couldn't do the scaling at
load time.
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.
