build: move required build to JDK 17, support Java8.

[iBotPeaches]

This is JDK v17

[iBotPeaches]

Pretty sure we can change the build version to 17+ and still produce Java 8 compatible binaries. My only fear that people depend on source builds on 8 which we've kept supported.

I'll sit on this, but I needed this with the changes on Sonatype/Maven Central

[Copilot]

Pull request overview

This PR updates the build/publish tooling to target the newer Vanniktech Maven Publish plugin (v0.37.0) and standardizes the build to run on JDK 17, while still compiling subprojects to Java 8 bytecode via --release 8. It also adjusts CI to always build with JDK 17 and run tests across a JVM matrix via Gradle toolchains.

Changes:

• Bump com.vanniktech.maven.publish to 0.37.0 and update internal publishing docs to Maven Central credential naming.
• Enforce JDK 17+ for builds; configure Gradle toolchains to build on JDK 17 and optionally run tests on other JVMs via -PtestJdkVersion.
• Update GitHub Actions CI to build with JDK 17 and pass the test JVM version to Gradle.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
settings.gradle.kts	Adds Foojay toolchain resolver plugin to enable auto-downloading toolchain JDKs.
INTERNAL.md	Updates Maven Central credential property names and JDK guidance; adds publishing-related notes.
gradle/libs.versions.toml	Bumps Vanniktech Maven Publish plugin version to 0.37.0.
build.gradle.kts	Enforces JDK 17+, configures toolchains, and adds test JVM selection via Gradle toolchains.
brut.apktool/apktool-cli/build.gradle.kts	Removes the JDK 11-only gate so proguard runs under the new JDK 17 build requirement.
.github/workflows/build.yml	Builds on JDK 17 and runs tests across a JVM matrix using -PtestJdkVersion.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[iBotPeaches]

@copilot - how can I confirm that the runner is actually using an older java version? I don't want this to accidentally hide issues on older version. I need extreme certainty the suite is running the older version

[Copilot]

@copilot - how can I confirm that the runner is actually using an older java version? I don't want this to accidentally hide issues on older version. I need extreme certainty the suite is running the ...

I've added a doFirst block to every Test task (commit build: log test JVM path and version in doFirst). When -PtestJdkVersion is passed, each test task will now print a line like:

[apktool-lib] Test JVM: /home/runner/.gradle/jdks/azul-zulu-8.0.432-linux-x64/bin/java (runtime: 1.8.0_432)

This appears in the CI log before the first test class runs, so you get the full executable path (confirming it's not the build JDK at /opt/hostedtoolcache/Java_Zulu_jdk/17.x.x) and the exact runtime version string — no guessing required.

[iBotPeaches]

@copilot - why is there no output of how many tests failed/worked? I think its odd. I'd like to see in build output how many tests ran

[Copilot]

@copilot - why is there no output of how many tests failed/worked? I think its odd. I'd like to see in build output how many tests ran

Added in the latest commit. Every test task now logs failed/skipped events inline and prints a summary line at the end of each subproject's test run, e.g.:

[apktool-lib] Tests: 842 passed, 0 failed, 0 skipped (total: 842)

This applies to all builds, not only when -PtestJdkVersion is passed.

[iBotPeaches]

@copilot - is it not possible for id("org.gradle.toolchains.foojay-resolver-convention") version "1.0.0" to use the libs.versions.toml?

[Copilot]

@copilot - is it not possible for id("org.gradle.toolchains.foojay-resolver-convention") version "1.0.0" to use the libs.versions.toml?

Unfortunately no — I tested it and Gradle rejects it with Unresolved reference: libs. The plugins {} block in settings.gradle.kts runs before the version catalog machinery is initialised, so the type-safe libs accessor is not yet available there. This is a known Gradle limitation: version catalog aliases are only accessible in project-level build scripts, not in the settings-file plugins block. The hardcoded version "1.0.0" is the only option here.