Thank you for your prompt reply George.
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.sowhich 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.