Clear AGP-10 deprecations + enable Gradle configuration cache

[hawkff]

Summary

Follow-up to #61. Clears the two AGP-10 deprecation warnings AGP 9 emitted and enables the Gradle configuration cache.

Changes (gradle.properties only)

• Remove android.enableJetifier=true. ./gradlew checkJetifier reports "Project ':app' does not use any legacy support libraries", and no com.android.support / android.arch artifacts appear in the resolved runtime classpath. Jetifier was transforming nothing. The flag is removed in AGP 10, so omitting it adopts the default (false).
• Remove android.nonFinalResIds=false to adopt the AGP 9 default (true). The only risk with non-final R ids is Java switch (R.id.x) / case R.id.x: (which require compile-time constants); the project has none — every Java switch is on protocol / type / authType ints. Flag is removed in AGP 10.
• Enable org.gradle.configuration-cache=true (stable since Gradle 8.1; project is on 9.4.1).

Testing

• ./gradlew checkJetifier → "does not use any legacy support libraries… you can disable Jetifier".
• No Java switch/case on R.* resource IDs (verified across app/src).
• Config cache verified end-to-end on JDK 17:
  • Run 1 (clean): "Configuration cache entry stored", no problems reported.
  • Run 2 (re-run): "Reusing configuration cache", build time 47s → 1s.
  • renameApksForOssDebug still runs and produces NekoBox-1.4.2-mod-12-<abi>.apk in both runs.
• No AGP deprecation warnings remain in the build output.

Greptile Summary

This PR removes two deprecated gradle.properties flags (android.enableJetifier=true and android.nonFinalResIds=false) that AGP 10 drops and enables the Gradle configuration cache (org.gradle.configuration-cache=true), which has been stable since Gradle 8.1 and the project is on 9.4.1.

• android.enableJetifier is removed after checkJetifier confirmed no legacy android.support.* artifacts are in use; omitting it adopts the AGP 9 default of false.
• android.nonFinalResIds=false is removed to adopt the AGP 9 default (true/non-final), which is safe because there are no Java switch/case statements on R.* resource IDs anywhere in the project.
• The configuration cache is enabled; the custom RenameApkTask in buildSrc uses proper Gradle lazy APIs and was empirically verified to serialize and reuse correctly.

Confidence Score: 5/5

Safe to merge — all three changes are removals or opt-ins to well-established defaults, and the custom build logic in RenameApkTask was verified to work correctly with the configuration cache.

The only file changed is gradle.properties, and each of the three modifications has been empirically tested: checkJetifier confirmed Jetifier was a no-op, a codebase-wide scan confirmed no Java switch/case on R.id constants, and a two-run configuration-cache test showed both cold-store and warm-reuse working end-to-end.

No files require special attention.

Important Files Changed

Filename	Overview
gradle.properties	Removes two AGP-10-dropped flags (android.enableJetifier, android.nonFinalResIds) and enables org.gradle.configuration-cache=true; all three changes are well-justified and the custom RenameApkTask implementation is configuration-cache-compatible.

_{Reviews (1): Last reviewed commit: "Adopt AGP 9 defaults + enable Gradle con..." | Re-trigger Greptile}

[coderabbitai]

Warning

Review limit reached

@hawkff, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 20 minutes. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 130eb2c4-f423-43c1-8abc-d0a4fba10716

📥 Commits

Reviewing files that changed from the base of the PR and between b23314d and bda99d5.

📒 Files selected for processing (1)

• gradle.properties

---

_{Comment @coderabbitai help to get the list of available commands.}