DexFileSplitter is based on dx, and dx is no more #15957
Assignees
Labels
Comments
|
@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? |
|
We're already looking into implementing this, thanks for the support |
|
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. |
copybara-service bot
pushed a commit
that referenced
this issue
Aug 4, 2022
… moving to D8. See #15957 The library is retrieved from https://android.googlesource.com/platform/dalvik/+/5a81c499a569731e2395f7c8d13c0e0d4e17a2b6/dx/src/com/android/dex/ and corresponds to the recent update of the Android dex library internally at CL 451207830. Change-Id: Id71bf5b41fda2993e6e577f158016665f33cd5e7 Signed-off-by: John Cater <[email protected]>
|
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 (8e259a3). It's almost a standalone library anyway. |
copybara-service bot
pushed a commit
that referenced
this issue
Aug 9, 2022
…_android_tools for bazel remote Android tools. This will require a new release of the bazel remote Android tools. See #15957. RELNOTES: None PiperOrigin-RevId: 466196935 Change-Id: I1670985368ad65c238ab98110bfce518694ab442
aiuto
pushed a commit
to aiuto/bazel
that referenced
this issue
Oct 12, 2022
…x to depending on the android_dex library from the remote Android tools. Before this can be submitted, first unknown commit must be submitted and then the bazel remote Android tools must be updated to include unknown commit. Fixes bazelbuild#15957. RELNOTES: None PiperOrigin-RevId: 468040969 Change-Id: Ia8ae2ef9c78ad6c88132a6de70666b15b2ecb1d8
6 tasks
BenHenning
added a commit
to oppia/oppia-android
that referenced
this issue
Jun 13, 2024
## Explanation Fixes #5370 Fixes part of #59 This PR updates the project to use Bazel 6.5.0 instead of 4.0.0. Note that most of the changes done so far in addressing #59 are centered around the concept of simplifying the Bazel maintenance as much as possible so that it's not too much more difficult than Gradle by the time we fully remove Gradle support from the project. While Bazel will always require more effort, there are many things that can be done to narrow the gap. This is a major step in that process since Bazel 4.x required using a custom Android toolchain (https://github.com/oppia/oppia-bazel-tools) which is not at all user friendly. Plus, there are many compatibility and performance improvements in later versions of Bazel that we want to be able to incorporate within the broader Oppia Android project. Bazel 6.x was specifically chosen because: - Bazel 4.x was missing support for the new D8 version which made it impossible to upgrade past 29.0.2 build tools bazelbuild/bazel#13989. - Bazel 5.x had some additional compatibility issues with the D8 change, so we weren't able to use it, either: bazelbuild/bazel#15957. - Bazel 7.x (which wasn't released when this work was originally done) introduces new bzlmod support that causes some additional build headaches that can be figured out later. - Bazel 6.5.0 specifically was chosen since it's the latest 6.x version (as of this edit) and seems to work correctly with existing unit tests. Some other important details to note: - rules_kotlin 1.7.x is needed at a minimum for Bazel 5.x+ support. However, an additional fix was needed (bazelbuild/rules_kotlin#940) in order to fix a deviation in functionality that occurred starting in Bazel 5.x's java_plugin support which led to some file duplication in rules_kotlin (that was fortunately easy to fix). Unfortunately, this change wasn't backported to 1.7.x so this PR makes use of a custom patch to rules_kotlin 1.7.1 (https://github.com/oppia/rules_kotlin) that includes the needed change. We'll get this change properly once we can upgrade to 1.8.x, though that will also require updating Kotlin itself to 1.8.x due to bazelbuild/rules_kotlin#1019. - Bazel 6.x (maybe 5.x) requires at least build tools 30.0.0 since it completely removed support for the old D8 compat dexer. 32.0.0 was chosen in this PR as it's simply a newer, more up-to-date build tools (and removes D8 completely). With this upgrade to Bazel 6.x we'll be able to update the build tools version more often (so long as it doesn't introduce AGP incompatibilities since we can't upgrade Gradle). - As of Bazel 6.x, we're able to reenable Java header compilation and incremental dexing, both of which should have _significant_ performance improvements for incremental builds of the app (and in fact we will have build errors if we disable incremental dexing). - In CI, we opted to **not** support build tools 29.0.2 or old builds of the app. Instead, we'll rely on build tools failing for certain PRs as an indicator that those PRs will require an update (once this PR is merged) in order to have CI run correctly. This is a lot easier than trying to figure out how to support before/after changes with some fairly complex environment differences. - There are a bunch of version updates that were needed to support the minimum version of Kotlin for rules 1.7.x (1.6 I think) as well as JDK 11 (which I think was needed for Bazel 5.x), and these have largely been taken care of in previous PRs to this one (though the JDK 11 update in CI was done in this PR, along with wiki documentation updates to address #5370). One such case of a necessary version upgrade: google/dagger#2511. - There was a change needed for the databinding java_plugin declaration to specify that it generates an API (in order for it to be used correctly in builds). - rules_java needed to be updated to support the newer version of Bazel. - The desugaring hack needed for kotlinx-coroutines-core-jvm was removed since it's no longer needed with the build tools & Bazel upgrade introduced in this PR. - This includes one small change in third-party to change all single-export wrappers that don't have additional plugins being enabled to aliases instead. This is more semantically correct as the wrappers may lose information (which caused problems when investigating adding Jetpack Compose support in #5401). While this isn't directly required for the Bazel upgrade, this is the last PR needed for Jetpack Compose support so it's being added here for simplicity. - ``.bazelrc`` was updated to configure tools, tests, and builds to all use the remote JDK 11 available via Bazel rather than ever using the user's local JDK. This should improve build hermeticity and consistency across different user environments (see https://bazel.build/docs/bazel-and-java). - Setup docs were updated to remove setting up JDK 11 (or Java at all for Linux & Mac) now that the user no longer needs to install Java (see previous point) except for Windows. The Python instructions were also removed since Bazel 6.x includes fixes for Android tools that previously depended on Python 2.x. - CI was unchanged for Java setup since, as far as I can tell, it's still needed for sdkmanager. There was also some small cleanup in unit_tests.yml that I noticed when updating CI versions. ## Essential Checklist - [x] The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".) - [x] Any changes to [scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets) files have their rationale included in the PR explanation. - [x] The PR follows the [style guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide). - [x] The PR does not contain any unnecessary code changes from Android Studio ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)). - [x] The PR is made from a branch that's **not** called "develop" and is up-to-date with "develop". - [x] The PR is **assigned** to the appropriate reviewers ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)). ## For UI-specific PRs only N/A -- This is a build infrastructure change. It shouldn't impact the end user experience. --------- Co-authored-by: Adhiambo Peres <[email protected]> Co-authored-by: Sean Lip <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 insteadimport the dex parsing code from dx for DexFileSplitter. Targeting this for Bazel 6.0The text was updated successfully, but these errors were encountered: