It was mis-lexing the case when a class descriptor is immediately
followed by a primitive type. The primitive type was being lexed as
PARAM_LIST_OR_ID_PRIMITIVE_TYPE instead of PRIMITIVE_TYPE.
The root cause was due to an incorrect state change. Since the
CLASS_DESCRIPTOR state can be started from within the PARAM_LIST state,
but when the CLASS_DESCRIPTOR state ends it just went back to YYINITIAL,
instead of going back to PARAM_LIST.
This adds a state stack to track these state changes
This unifies the handling of simple names between class descriptors and
member names, and ensures that spaces are only allowed for the appropriate
api levels in both cases
DEX format allows Unicode space characters in SimpleName since version 040.
Allowed space characters include everything in Unicode category 'Zs':
0x20, 0xa0, 0x1680, 0x2000..0x200a, 0x202f, 0x205f, 0x3000
Smali now supports symtax `method with spaces` (spaces are allowed in
backtick-quoted names).
In api 28, the vdex files in, e.g. the framework/arm directory are actually
just sym links to a shared vdex file in the framework directory. However,
the sym links use an absolute path, and so they don't resolve correctly in
the loop mounted system image.
As a simple workaround, we'll just search upward one directory in the path
if the vdex file can't be resolved.
Oat version 138 introduced the concept of an "uncompressed" dex file, where
the dex file is listed in the oat file, but it's not actually present in
the oat or vdex files, instead, it's in the apk as per usual.
This change makes dexlib2 ignore these files, treating them as if they are
not a part of the oat file.
Newer versions of art seem to use ! instead of : to separate the
inner dex filename from the name of the container containing it.
e.g.
/system/framework/framework.jar!classes2.dex
instead of
/system/framework/framework.jar:classes2.dex
Loading cdex files is mostly supported, except for the new debug info
structures.
Dumping is somewhat supported, but only when there's a single cdex file
in the vdex.
For cdex files, offsets into the data section are specified relative to
the start of the data section, instead of relative to the start of the dex
file.
This adds a separate data buffer that can be used to resolve these
references.
isOdexFile was no longer being used, and hasOdexOpcodes had a slightly
misleading name, since it could potentially return true for an odex or
oat embedded dex file that didn't actually have any odex opcodes.
