ci: raise Gradle MaxMetaspaceSize to 1g to fix Publish Release OOM

[sherwinski]

Summary

• The Publish Release workflow failed on 2026-04-28 during the Dry Run - Publish to Maven Local with signing step with java.lang.OutOfMemoryError: Metaspace while running :OneSignal:location:javaDocReleaseGeneration (Dokka).
• Gradle logged that the configured max Metaspace was 512 MiB, which Dokka exhausts because it loads class metadata for every submodule (core, in-app-messages, notifications, otel, location, etc.).
• Bumps MaxMetaspaceSize from 512m to 1g in OneSignalSDK/gradle.properties.

Failure excerpt

Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Metaspace
> Task :OneSignal:location:javaDocReleaseGeneration FAILED
...
* What went wrong:
Execution failed for task ':OneSignal:location:javaDocReleaseGeneration'.
> A failure occurred while executing com.android.build.gradle.tasks.JavaDocGenerationTask$DokkaWorkAction

Test plan

• CI green on this PR
• Re-run the Publish Release workflow after merge and confirm the dry-run publish + Dokka tasks complete successfully

[Copilot]

Pull request overview

Adjusts Gradle JVM metaspace settings to prevent CI OOM failures during Dokka/Javadoc generation in the “Publish Release” workflow.

Changes:

• Increased Gradle daemon -XX:MaxMetaspaceSize from 512m to 1g to accommodate Dokka’s class-metadata usage across many submodules.

---

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

[claude]

LGTM, straightforward CI fix bumping Gradle Metaspace from 512m to 1g to address the documented Dokka OOM.

Extended reasoning...

Overview

This PR makes a single one-line change in OneSignalSDK/gradle.properties, raising -XX:MaxMetaspaceSize from 512m to 1g. It is purely a build-time JVM tuning change to address an OutOfMemoryError observed in the Publish Release workflow during :OneSignal:location:javaDocReleaseGeneration (Dokka).

Security risks

None. This is build configuration that only affects the Gradle daemon's JVM memory limit during local/CI builds. It does not touch any product code, dependencies, signing, or release artifacts.

Level of scrutiny

Minimal scrutiny is appropriate. The change is mechanical, the failure is well-documented in the description with an excerpt, and the fix matches the diagnosed cause (Dokka loading metadata across many submodules exhausts Metaspace). -Xmx4096m is unchanged, so total memory pressure on CI runners remains bounded.

Other factors

No prior reviewer comments. No bugs were flagged by the bug hunting system. The only follow-up is verifying the Publish Release workflow runs green after merge, which is already captured in the PR's test plan.