refactor: ExtDataInput rework, source layout and formatting #3738
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor ExtDataInput classes: ExtDataInput is now the extended interface, ExtDataInputStream is an easy-to-use FilterInputStream implementing ExtDataInput with static creator methods for big-endian and little-endian wrappers.
Refactor AaptManager class: unify aapt-related verifications to one class.
Replace Apache Commons' deprecated CountingInputStream with Google Guava's equivalent with the same name. Apache's BoundedInputStream is an overkill for our use case and its constructors are deprecated as well.
Normalize source layout to have a common and somewhat more standard order: Static fields first, instance fields after, methods last.
Fix some formatting, like empty spaces or extra spaces and exception messages.
Renamed ResXmlPatcher to ResXmlUtils, as it has more purposes than just patching.
Renamed DirUtil to DirUtils, to match other utility classes naming convention.
Moved "properties/apktool.properties" to jar's root, to match smali/baksmali.
Moved Android Framework to "prebuilt", as it is just a prebuilt, looks out of place among .class files.
@SuppressWarnings removed from Duo as there are quite a few unsafe assignments of raw Duo[] instances to parameterized Duo<> variables in the project, this is just Java being the primitive boilerplate it is, no point in fighting it.
No end-user changes.
Tested against a full ROM decompile/recompile, no issues found.