android/build.gradle applies Kotlin Gradle Plugin directly — breaks under Flutter's Built-in Kotlin migration

[Sreinigung]

What's happening

Every Android build of an app using this plugin (v0.0.3) prints:

WARNING: Your app uses the following plugins that apply Kotlin Gradle Plugin (KGP): ar_flutter_plugin_2
Future versions of Flutter will fail to build if your app uses plugins that apply KGP.

See Flutter's migration guide: https://docs.flutter.dev/release/breaking-changes/migrate-to-built-in-kotlin/for-plugin-authors

Cause

android/build.gradle declares its own Kotlin Gradle Plugin classpath and applies it the classic way:

buildscript {
    ext.kotlin_version = '1.9.10'
    ...
    dependencies {
        classpath 'com.android.tools.build:gradle:8.3.2'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}
...
apply plugin: 'kotlin-android'

Flutter's newer "Built-in Kotlin" support expects plugins to not apply their own KGP instance — Flutter's Gradle plugin supplies it. As of the current main branch this hasn't changed yet.

Impact

Currently just a warning — builds still succeed. But per the linked migration guide, a future Flutter release will refuse to build any app depending on a plugin that applies its own KGP this way, which would break every app using ar_flutter_plugin_2 on that Flutter version.

Suggested fix

Migrate android/build.gradle to the declarative plugins-block form Flutter's guide recommends (roughly):

plugins {
    id 'com.android.library'
    id 'org.jetbrains.kotlin.android' apply false
}

and let Flutter's Gradle plugin supply the actual Kotlin Gradle Plugin version, rather than declaring a separate buildscript { classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:...' } block.

Happy to test a patched version against a real device if a branch/PR is put up — this plugin is a dependency of a small production app we maintain.

[m-speiser]

Separate but likely related finding while investigating this issue further: on a Samsung Galaxy S24 running Android 16 (API 36), any app using this plugin's ArView crashes reproducibly and immediately whenever the AR camera view is started (both a fresh calibration flow and normal AR area measurement — confirmed 3/3 attempts, including a log entry from before this was being actively investigated, so it's not a permission-dialog timing race).

Root cause per adb logcat: io.github.sceneview:arsceneview:2.2.1 (the compiled dependency this plugin pulls in via implementation) throws an uncaught com.google.ar.core.exceptions.SessionPausedException from its own ARSceneView.onFrame() → ARSession.updateOrNull() → Session.update() — before reaching the app-supplied onFrame callback in ArView.kt, which already has its own catch (e: SessionPausedException) (silently skips the frame) — but that catch never runs for this particular call path, since the throw happens inside arsceneview's own base onFrame(), one level up from the plugin's callback:

FATAL EXCEPTION: main
com.google.ar.core.exceptions.SessionPausedException
	at com.google.ar.core.Session.throwExceptionFromArStatus(Session.java:16)
	at com.google.ar.core.Session.nativeUpdate(Native Method)
	at com.google.ar.core.Session.update(Session.java:2)
	at io.github.sceneview.ar.arcore.ARSession.updateOrNull(ArSession.kt:103)
	at io.github.sceneview.ar.ARSceneView.onFrame(ARSceneView.kt:477)
	at io.github.sceneview.SceneView$FrameCallback.doFrame(SceneView.kt:876)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1959)
	...

This is consistent with the 16KB page-size issue also visible in this app's build/install output on the same device (libarcore_sdk_jni.so, libfilament-jni.so, libarcore_sdk_c.so etc. reported as not 16KB-page-size compatible) — plausibly the native ARCore session never actually initializes correctly on this device/OS combination, so it stays permanently "paused" from the app's point of view, and every subsequent frame update throws.

Since the throwing call is inside the compiled arsceneview dependency (no source access to patch it directly, and it's pulled in as implementation so it's not even on the consuming app's compile classpath), we worked around it app-side with a targeted Thread.setDefaultUncaughtExceptionHandler in our MainActivity that specifically matches this one exception type (by class name, walking the cause chain) and restarts Looper.loop() on the main thread instead of letting the process die — a plain setDefaultUncaughtExceptionHandler that just logs and returns isn't enough here, since by the time it runs the exception has already unwound Looper.loop(), so the message queue has to be explicitly re-pumped. Happy to share the ~30-line Kotlin snippet if useful.

To be clear, this is damage control, not a real fix — the AR camera itself still never produces a live preview on this device, so the underlying native incompatibility remains. Flagging it here since it looks like the same root cause area (this plugin's outdated pinned dependencies vs. current Android versions) rather than opening a separate issue — happy to move it if a dedicated issue is preferred.