Summary
com.arashivision.sdk:sdk-camera:2.1.5 resolves com.arashivision.sdk:graphicpath:2.901.4, and that artifact still references classes in com.arashivision.insbase.*. The insbase artifact is no longer published on the SDK Maven repository, so those references cannot be resolved by any consumer.
Debug builds are unaffected. Any release build with R8/ProGuard enabled fails.
Evidence
insbase 404s on the SDK repo:
$ curl -s -o /dev/null -w "%{http_code}\n" -u "$USER:$PASS" \
https://androidsdk.insta360.com/repository/maven-public/com/arashivision/insbase/maven-metadata.xml
404
It is also absent from the resolved graph of sdk-camera:2.1.5, which pulls camerastream, onestream, minicamera, ins_ble, ins_socket, ins_usb, fastble, sdk-common, graphicpath, sdk-bridge and com.insta360.infrastructure:thread — but no insbase. On the 1.x line com.arashivision:insbase:2.756.9 was in the graph, which is why this only appears after migrating to 2.x.
R8 output:
ERROR: R8: Missing class com.arashivision.insbase.arlog.Log
(referenced from: long com.arashivision.graphicpath.base.EglContextGroup.acquireEglContext(java.lang.Object)
and 33 other contexts)
Missing class com.arashivision.insbase.joml.Matrix4f
(referenced from: com.arashivision.insbase.joml.Matrix4f com.arashivision.graphicpath.render.engine.Camera.getInverseWorldMatrix()
and 10 other contexts)
Missing class com.arashivision.insbase.nativeref.NativeObjectRef
(referenced from: void com.arashivision.graphicpath.insmedia.common.MediaFrame.<init>(long, java.lang.String)
and 109 other contexts)
...13 missing classes in total
> Execution failed for task ':app:minifyDevReleaseWithR8'.
The referenced packages are com.arashivision.insbase.arlog, .joml (Matrix4f/Matrix4fc/Quaterniond/Quaternionf/Quaternionfc/Vector2f/Vector3f/Vector3fc/Vector4f) and .nativeref (NativeBuffer/NativeObjectRef).
Separately, org.slf4j.impl.StaticLoggerBinder is also reported missing — that one is benign (slf4j-api with no binding falls back to its no-op logger) and only worth mentioning because it appears in the same output.
Why this may not have been noticed
AndroidSDKDemo/app/build.gradle.kts sets isMinifyEnabled = false, so R8 never runs over the SDK in the sample project.
Workaround
-dontwarn com.arashivision.insbase.**
This is safe for us only because we do not depend on sdk-media and never construct a renderer, so the graphicpath paths are unreachable. A consumer that does use preview or on-device stitching would presumably hit NoClassDefFoundError at runtime instead of a build failure, which is a considerably worse outcome.
Ask
Either publish insbase again so the references resolve, or ship the ProGuard/R8 consumer rules with graphicpath (an AAR can carry its own proguard.txt) so consumers do not have to discover this themselves.
Related: the proguard.txt files shipped inside sdkcamera and basecamera on the 1.x line were 0 bytes, and the other AARs shipped none — so nothing currently stops R8 renaming or stripping SDK classes that are resolved reflectively or from JNI. Consumer rules for the 2.x artifacts would help there too.
Summary
com.arashivision.sdk:sdk-camera:2.1.5resolvescom.arashivision.sdk:graphicpath:2.901.4, and that artifact still references classes incom.arashivision.insbase.*. Theinsbaseartifact is no longer published on the SDK Maven repository, so those references cannot be resolved by any consumer.Debug builds are unaffected. Any release build with R8/ProGuard enabled fails.
Evidence
insbase404s on the SDK repo:It is also absent from the resolved graph of
sdk-camera:2.1.5, which pullscamerastream,onestream,minicamera,ins_ble,ins_socket,ins_usb,fastble,sdk-common,graphicpath,sdk-bridgeandcom.insta360.infrastructure:thread— but noinsbase. On the 1.x linecom.arashivision:insbase:2.756.9was in the graph, which is why this only appears after migrating to 2.x.R8 output:
The referenced packages are
com.arashivision.insbase.arlog,.joml(Matrix4f/Matrix4fc/Quaterniond/Quaternionf/Quaternionfc/Vector2f/Vector3f/Vector3fc/Vector4f) and.nativeref(NativeBuffer/NativeObjectRef).Separately,
org.slf4j.impl.StaticLoggerBinderis also reported missing — that one is benign (slf4j-api with no binding falls back to its no-op logger) and only worth mentioning because it appears in the same output.Why this may not have been noticed
AndroidSDKDemo/app/build.gradle.ktssetsisMinifyEnabled = false, so R8 never runs over the SDK in the sample project.Workaround
This is safe for us only because we do not depend on
sdk-mediaand never construct a renderer, so thegraphicpathpaths are unreachable. A consumer that does use preview or on-device stitching would presumably hitNoClassDefFoundErrorat runtime instead of a build failure, which is a considerably worse outcome.Ask
Either publish
insbaseagain so the references resolve, or ship the ProGuard/R8 consumer rules withgraphicpath(an AAR can carry its ownproguard.txt) so consumers do not have to discover this themselves.Related: the
proguard.txtfiles shipped insidesdkcameraandbasecameraon the 1.x line were 0 bytes, and the other AARs shipped none — so nothing currently stops R8 renaming or stripping SDK classes that are resolved reflectively or from JNI. Consumer rules for the 2.x artifacts would help there too.