for better performance. Without the optimization, these two functions
may check more than 100k file names in the pre-installed APK files,
which can take a few seconds to finish even on a recent device.
Bug: 21957428
Change-Id: I315fd3c6d5aa1076b993752525de449a9933de12
getEntryInfo crashes on 64-bit devices because "long" types
were being passed int pointers (that pointed to a stack frame)
that were reinterpret_cast'ed to long* (sigh.). To fix this issue
once and for all, use types with explicitly defined widths.
This change also removes some dead invariant checking from
Asset.cpp instead of cleaning it up.
Note that we've introduced a wart in NativeLibraryHelper, where
we need to deal with zlib's uLong type, which is "at least 32 bits
wide".
bug: 21622286
(cherry picked from commit 4600dd053dbdbd4b95f3b11057a1cc55b99f9c77)
Change-Id: I7886cb37a229cc27c625699c80e6a6a6117d2203
getEntryInfo crashes on 64-bit devices because "long" types
were being passed int pointers (that pointed to a stack frame)
that were reinterpret_cast'ed to long* (sigh.). To fix this issue
once and for all, use types with explicitly defined widths.
This change also removes some dead invariant checking from
Asset.cpp instead of cleaning it up.
Note that we've introduced a wart in NativeLibraryHelper, where
we need to deal with zlib's uLong type, which is "at least 32 bits
wide".
bug: 21622286
Change-Id: Iae675a9601db7aae03a8b80b40321d2cc1d97f50
I've inspected all other callers of OpenArchive and this seems
to be the only broken one. The easiest way to reproduce this is
by using getPackageArchiveInfo or by adding an asset path that
isn't a valid APK.
bug: https://code.google.com/p/android/issues/detail?id=171099
Change-Id: I41cd85d20f26ad47968e2a6f1384cc03330b558b
This lets us share zip archive processing code with both
the runtime (Art, dalvik) and critical java code
(StrictJarFile).
This change also moves several utility methods to ZipUtils
and dedups code across several zip inflation methods.
One of the side effects of this change is that several
processing loops are now O(n) instead of O(n^2).
bug: 10193060
Change-Id: I3c7188496837a47246c4f342e45485a70fef3169
Reconcile the difference between ZipFileRO and java.util.ZipFile to have
the same behavior.
Bug: 10424836
Change-Id: I6bde1bad7e20065ee650945fd43a913c05ce5ac7
Reconcile the difference between ZipFileRO and java.util.ZipFile to have
the same behavior.
Bug: 10424836
Change-Id: Iff159c9e1a91b59f6c5346dc0278cb9e4bbc1a39
ZipUtils is needed by build/tools, move it from libandroidfw
(frameworks/base) to libutils (frameworks/native).
Change-Id: I2b4b7adcdf68eb25ee7cba5dd3b69eadf0523af3