DexFileSplitter is based on dx, and dx is no more

[ahumesky]

The last version of the build-tools in the Android sdk to include dx was 30.0.3. The last significant tool to use dx is DexFileSplitter, so ~~it should be rewritten to use D8 instead~~ import the dex parsing code from dx for DexFileSplitter. Targeting this for Bazel 6.0

[mauriciogg]

@ahumesky are you open to contributions for this. We are open to do the implementation work here - looks like it boils down to just figuring out the equivalent classes in the d8.jar?

[ahumesky]

We're already looking into implementing this, thanks for the support

[mauriciogg]

btw I think you can get away with not doing anything special just by using a custom built r8 (https://partnerissuetracker.corp.google.com/issues/240438146). Thats what we are doing internally. The only problem is it looks like this is not officially supported. In any case its likely that just using the manve/android_sdk r8 jar to replace the old dexer code wont be possible since almost all of the classes are optimized out.

[ahumesky]

Yeah, exactly, so D8 has APIs for getting the kind of information that DexFileSplitter uses (the "inspection" API), however they're not designed to be used in a tight loop like DexFileSplitter does. D8 has dex parsing code, but none of it is public, and in talking with the D8 team, there aren't plans to support that. So the next best thing is to just import the dex parsing parts of dx (https://github.com/bazelbuild/bazel/commit/8e259a340d4196d64650aaf88797a06603cb3392). It's almost a standalone library anyway.