When attempting to integrate Leia CNSDK in existing android app, the app gets stuck at Leia facetracking permission dialog. The dialog seems to assume tablet real estate which means on phones the formatting is horrible and the buttons are not displayed, meaning the user is unable to grant permission to advance past the dialog screen.
Usually the CNSDK sample app runs OK on phones, but on one occasion was able to reproduce the problem when running the CNSDK sample app; screenshot attached. It can be observed that the margins squeeze the text into an impossibly narrow region which causes the buttons to be truncated.
So the user sees a narrow strip of text with no way to proceed, which would likely read to poor app reviews and a negative user experience when an app with optional LumePad support was running on non-Leia hardware.
The two buttons which are not displayed are
“Enable FaceTracking”
and
“Disable and close the App”
If those buttons were successfully displayed, in theory the user could bypass the dialog.
Also, it is a mystery why this dialog appears every time when the CNSDK has been integrated into a real world complex app, but rarely in the CNSDK sample app, even when running on non-Leia hardware.
Hi Steve, you are right that CNSDK assumes to be running on a tablet only. That’s because it officially supports LumePad2 only. Feature versions will support phone layouts as well.
However, this dialog shows up only when CNSDK is initialized. And I don’t exactly understand why would you initialize CNSDK on a non-Leia platform. Could you please clarify that?
I was just going with the code in the sample app. Does the sample app check what hardware it’s running on? If so I couldn’t see it. At first I thought it might be due to the app requesting camera permission, but adding camera permission to the sample app didn’t trigger the dialog reliably so couldn’t determine definitively. My guess is there’s some interplay going on in a complex real-world app that doesn’t happen in the “toy” sample project; either that or I missed something obvious in the sample app code.
My wish would be for the CNSDK to detect whether it’s running on Leia hardware and if not simply disable/no-op actual calls, if there’s any danger of hanging the client app. This would reduce duplication of effort (and bugs ) in apps which are consumers of the CNSDK and make it easier to integrate, which should contribute positively to adoption
Here is my shortlist for what I would deem to be acceptance criteria for integrating the Leia CNSDK into apps which would offer optional LumePad support:
Provide all 4 supported NDK ABIS: arm64-v8a, armeabi-v7a, x86_64, x86
Leia hardware doesn’t require those .so files, but candidate apps with C/C++ code are highly likely to, and may be averse to committing to the effort of guarding against loading libs if on non-Leia hardware (attempting to load a missing .so will crash-on-launch, here is an actual example where a project didn’t ship with an ABI which triggered crashes)
Reduce the minimum API version from 29 to ideally 23 or 24. While there is a manifest flag to force override, the Leia CNSDK brings in the libbinder_ndk.so which isn’t available on devices running older than API 29. So an app that used to run perfectly on old hardware would suddenly start crashing on launch simply by adopting the Leia CNSDK (developers don’t like it when importing a 3rd party dependency also imports restrictions and constraints )
Preventing the FaceTracking permission dialog from appearing, or at least fixing the UI format so it shows its entire contents including the crucial buttons (perhaps using a nested scroll view so that even on smaller screens, the user would always be able to scroll to reveal the buttons) Or better yet figure out why the dialog appears in real-world apps but not the sample app and prevent it from being displayed at all; it seems to be bypassed 90% of the time in the sample app (but did observe it appear that one time when I made the screenshot). Certainly no reason to display it on non-Leia hardware, but consider that developers would not wish to put in the effort to reliably detect that situation…
Anyway I know this is a lot to ask and won’t happen quickly. I was able to add a column interleaved stereoscopic render technique via the stencil buffer, and this works perfectly on the IQHD “Skyy” tablet (and presumably other hardware with a fixed, passive lenticular layer), so my app does support stereoscopic 3D on some android hardware. Unfortunately due to the risk of breaking the app in the field, it isn’t possible to integrate the CNSDK in order to support Leia hardware yet.
I guess Android’s BUILD.* can be matched. My Lume Pad 2 arrives in a week or so, I’ll dump the various properties. There being only one hardware model available right now that supports the CNSDK, should be a simple test.
We use android.os.Build.PRODUCT == LumePadGen2 in CNSDK.
But we better improve the developer experience here. I see two quick solutions:
Fail LeiaSDK.createSDK on non-Leia devices.
Add a helper function in LeiaSDK to check if the current device is a Leia one.
The first solution will altogether prevent any kind of interference of CNSDK on other platforms. I can also move the System.loadLibrary call from the static block to createSDK. This will also nullify any kind of issues due to missing shared libraries.
Let me know what do you think.
Here is my feedback on your message from Jan 4:
Provide all 4 supported NDK ABIS:
This won’t happen in the foreseeable feature. I believe moving the System.loadLibrary call should resolve the issue.
Reduce the minimum API version from 29 to ideally 23 or 24
Should be doable, I will add it to our TODO list to do a quick check and will return to you with more information.
Preventing the FaceTracking permission dialog from appearing
Or better yet figure out why the dialog appears in real-world apps
I’m not entirely sure but I thing that’s due to the way it’s implemented currently (and II see no way of changing it) and the fact that there is no valid Leia FaceTracking service installed on the device. Should be also fixed by skipping or failing LeiaSDK.createSDK on non-Leia hardware.
) in apps which are consumers of the CNSDK and make it easier to integrate, which should contribute positively to adoption
)