12 Commits

Author SHA1 Message Date
Steven Moreland
fb7952f57e Don't use cutils/Atomic.h
Test: builds
Change-Id: I74485a5cbecb8710714f7bf3e54da61dd787838f
2018-02-23 15:02:42 -08:00
Adam Lesinski
d1ecd7af68 AssetManager2: Various fixes
- Use FileMaps to open Assets (prevents closing of ApkAssets underlying
zip)
- Implement OpenDir and List methods
- Fix issue where DynamicRefTable wasn't properly constructed

Test: make libandroidfw_tests
Change-Id: Ib21a84e1114d028120744aa3bc1c6eb9d9399fa8
2017-02-15 10:50:23 -08:00
Adam Lesinski
0358efe4f7 Fix race with Asset destruction and printing allocation stats
A race could occur when printing the list of Asset allocations for
debugging purposes.

Each Asset object would insert themselves into a global linked list
on construction and remove themselves on destruction. Iterating the list
and the insertion/remove operations all acquire a global lock.

The race occurs after the Asset subclass destructor runs but before the Asset
base class destructor runs, which performs the actual removal from the list.

The vtable of the object being destroyed ends up pointing at the base Asset class'
vtable, and during the iteration of the global list, a pure virtual method is called
leading to an abort, since the wrong vtable is dereferenced.

This change moves the insertion/removal of the Asset object into the global list
to the concrete class, which adds some maintenance overhead but solves the problem.

Bug:31113965
Test: make libandroidfw_tests
Change-Id: I1a620897e5e04a8519ee247883bba0719b1fa6f3
2016-10-17 14:04:09 -07:00
George Burgess IV
a346f5458a Cleanup uses of sprintf so we can deprecate it.
Change-Id: Ic66abfb547cd5551c47e03d604e65f83c84c597f
2016-03-02 13:34:44 -08:00
Narayan Kamath
4600dd053d ZipFileRO: Use precise widths for zip file types.
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
2015-06-17 08:40:25 +00:00
Narayan Kamath
688ff4cf0f Track removal of refcounts from FileMap.
Use delete instead of release.

Change-Id: I25c841b368aa9d51e9259399b94cafa2bbb7a076
2015-02-23 15:47:54 +00:00
Andreas Gampe
2204f0bf56 Frameworks/base: Wall Werror in libs/androidfw
Turn on -Wall -Werror in libs/androidfw. Fix warnings. Refactor
some code.

Change-Id: I66fe54ace433c15dee5de328b149ca142f74b2dd
2014-11-07 13:35:05 -08:00
Mark Salyzyn
00adb8685e androidfw: resolve 64-bit build issues
- uid_t/gid_t cast to unsigned long
- unused argument warnings
- tab and space requirements

Change-Id: Ib446d8165b9082be02edb55e6b71fd1a03ea3431
2014-03-19 11:11:14 -07:00
Narayan Kamath
afd31e0829 Reimplement ZipFileRO in terms of libziparchive.
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
2013-12-09 16:23:16 +00:00
Mathias Agopian
1f5762e646 libutils clean-up
Change-Id: I11ee943da23a66828455a9770fc3c5ceb4bbcaa9
2013-05-07 17:09:46 -07:00
Colin Cross
a982dc05d7 frameworks/base: move Zip* from libandroidfw to libutils
ZipUtils is needed by build/tools, move it from libandroidfw
(frameworks/base) to libutils (frameworks/native).

Change-Id: I2b4b7adcdf68eb25ee7cba5dd3b69eadf0523af3
2012-03-22 18:43:07 -07:00
Mathias Agopian
83c64e6b62 frameworks/base refactoring
create the new libandroidfw from parts of libui and libutils

Change-Id: I1584995616fff5d527a2aba63921b682a6194d58
2012-02-20 22:38:43 -08:00