| 27604018f783bf6354a13870b3e7785edca69b5f |
|
28-Sep-2016 |
Paul Duffin <paulduffin@google.com> |
Detect and fix resource leakages in tests
Tests that test those classes that use CloseGuard to detect
reosurce leakages are switched to use TestCaseWithRules and
ResourceLeakageDetector.getRule() to detect any resource
leakages and the leaks fixed.
A number of tests could not be fixed due to bugs in the core
classes so a new DisableResourceLeakageDetection annotation was
added as part of this change. A method annotated with that does
not perform resource leakage detection. The affected tests were
annotated with a description and a reference to an associated
bug.
This uses try-with-resources to aid in closing resources. While
that does provide some benefits it is all too easy to change the
behavior of the test unless care is taken. To avoid that it is
important not to merge it with an existing try block such as
those which follow the following pattern:
try {... fail()} catch(..) {}
Merging them could result in the test catching and ignoring
exceptions thrown during the creation of the resource which is
almost certainly not what the test was intending.
Test: Tested with vogar and CTS
Bug: 31542223
Change-Id: Id32bb40fe04eb9719d7e6cd367abb53118b21832
|
| a812a87e69850d1492c45bd88d7ff3dbf21d5075 |
|
24-Mar-2015 |
Narayan Kamath <narayan@google.com> |
Don't use zip64 by default.
This change was breaking tools like dexmaker that would write
zipfiles to disk so that the runtime could read them.
We don't want to go back and amend the local file header, so
we just throw an IOException if somebody writes more than 4GB
of data to an entry that doesn't have a declared size. If the
entry has a declared size > 4GB, we can write the zip64 header
in advance.
bug: 19574093
Change-Id: I771e821996efd3ef4c3de5e02f5a0062e62f9244
|
| 0aff1dd0b4be1b8d8cb45b59079ca883a1b3205a |
|
17-Jun-2014 |
Elliott Hughes <enh@google.com> |
Remove.
(cherry-pick of 63744c884dd4b4f4307f2b021fb894af164972af.)
Change-Id: Ibf79a402e1bad98a262e380fcee3d35c127ae6d5
|
| 63744c884dd4b4f4307f2b021fb894af164972af |
|
17-Jun-2014 |
Elliott Hughes <enh@google.com> |
Remove.
Change-Id: Ibf79a402e1bad98a262e380fcee3d35c127ae6d5
|
| e3d756c5dae1af2aa5f0ad8bc7f133df3e7401eb |
|
11-Mar-2014 |
Neil Fuller <nfuller@google.com> |
Add Java 1.7 APIs: ZipFile, ZipInputStream, ZipOutputStream
Add constructor support for the character encoding to use.
When reading a ZipFile this is used for the file comment and for
entry names and comments when a zip entry is not self-described
as UTF-8 encoded.
When writing a zip file the character encoding determines the
encoding used for the file comment, entry names and comments.
The default for reading and writing when the character encoding
is not specified remains as UTF-8.
Additional fix:
ZipOutputStream: null comments no longer cause NullPointerException.
Change-Id: I7cadfa939377d0f87fd5503dae2a0b2dbac2ba39
|
| ef164bf196538c04f499dcbb49a389c70ff5601a |
|
26-Feb-2014 |
Paul Duffin <paulduffin@google.com> |
Improve error message when attempting to open an empty zip
The bug report states that the behaviour of ZipFile has changed between 4.3 and
4.4 when opening an empty zip file. I did some investigation and it appears as
though the reference implementation also throws an exception in that case so I
decided that 4.4 is working as designed. However, to make it clearer I made a
minor change to explicitly check for an empty zip file so that we can report a
slightly improved message explaining that they are not supported. I added a
test for various forms of empty streams and zip files and removed part of an
older test from harmony tests as it is no longer necessary.
Bug: https://code.google.com/p/android/issues/detail?id=65380
Change-Id: I1f2fcbf6bbaedb7dbccf8dd4f1cec4e330274524
|
| 27495197b6f411df17116022bd0f5458aecd9c84 |
|
12-Nov-2010 |
Elliott Hughes <enh@google.com> |
A specific test for http://b/3181430.
Bug: 3181430
Change-Id: If1e02a888863143f4c56d1ef57e265d7c7bffcc4
|
| 55e276b6718282224e0069645da2222beda7b8df |
|
11-Nov-2010 |
Elliott Hughes <enh@google.com> |
Tests that would have caught my recent ZipInputStream/ZipOutputStream regressions.
Not the best tests in the world, but they would have been sufficient.
Bug: 3181430
Change-Id: Id68f5bb6a2c66f9f5c8c061b34dfeb5d3d63e63e
|