(I originally posted that question here, where I was requested by @martyone to post it as a separate topic), so…
Does anyone know how to make SDK launch projects on the device in sandboxed mode? Because if I configure the project for Sailjail and the SDK launches it in non-sandboxed mode then the app doesn’t have access to features protected with permissions (Contacts, call log, etc.). This makes testing and debugging very uncomfortable.
Try by running it under the privileged process group with the help of SGID file permission. You can achieve that e.g. with Custom Process Step deployment step under the IDE or by modifying the RPM .spec(*) temporarily (just during development, not for distributed packages), changing the corresponding line under the %files section to something like
Nope. I had tried that, although setting attr after should work as well? Trying it exactly the way you have here makes no diff. I made sure to run qmake and checked and double checked. Neither is the app running with QML live connections nor is it in a sandbox (ie. open the GPS pain in my app, immediate results. in sailjail, this is not the case.).
EDIT: I also removed all traces of the app, just in case. No. diff.
@martyone, thanks, this yaml modification works, too.
@poetaster Well, it’s not really a sandboxed mode, but in my case it gives access to privileged data while testing/debugging, which is what I needed. I’m developing an app accessing contacts and before I applied the above modification, I needed to deploy it from SDK, then stop it, then launch it from the device or via ssh (if I wanted to see qDebug or console.log output), or else it couldn’t access the contacts database. With this modification it has access to contacts right away, launched from the SDK. So for me it does its job.
Jeez, I think I’ve turned this on it’s head. I was looking for the Sailjail limits to be appllied. In my case, launching from the device does, of course, just that. But I was hoping for ‘within’ the SDK and with QML live debugging.
My problem is that the access to Location/Positioning has very odd delays and I wanted to see if I could counter that. In the end I’m better off editing the QML on the device and restarting the app. sigh. It’s a bit like old school html development (ducks and runs).
This is starting to be a little bit off topic, sorry about that. To me that sounds like there might be a bug somewhere. If you manage to isolate the problem into a minimal test case (i.e. an app which has only just enough functionality to demonstrate the bug and nothing else), please write a bug report about it.
I had filed a bug report,GPS location data not available in Sailjailed app - #8 by poetaster, but by setting PositionSource active (@karry ) I was able to get Position data. But, given location is on in advance, it is ‘immediately’ available when testing in the SDK. As soon as you start ‘normally’, accept sailjail, and navigate to it, it takes a very long time. I was about to rework the messages to reflect that, but could just start with the page as it is.
Never mind. I just made some minor change (message text) and it behaves more like I’d expect. It’s a bit confounding that, from the SDK (and also in 3.4 without sailjail) you see what appears to be the last known values? But, the delay doesn’t seem so abnormal anymore.
EDIT: on the other hand, debugging QML is a real pain. I’ll open another bug report.
Hi, sorry for late reply. I’ve tried to test it but it couldn’t find neither of the includes: livenodeengine.h
nor remotereceiver.h. They don’t seem to be included in the SDK.