Access to storage the usual way

Hi

Last update (2.0.15) totally breaks our workflow because of the new way to access local projects (“importing” instead of direct opening).
As we began far before Qfield Cloud, we use our own mechanisms (based previously on syncthing and now on GIT) to handle projects and bidirectional syncing.

My company (Tactis) is user of Qfield since 2017, and we have around 20 tablets using daily Qfield.

I understand it is related to android security policy… Is there really no workaround ? I noticed that “recent” shortcuts are still working without importing the projects.

At the moment we are forced to use older version because our workflow is not compatible with this change…

I’d like to investigate more Qfield Cloud, but it is still “beta”, and we have really heavy use with 10’s of Go of pictures etc… We are to much “in a rush”. I’ll think about if when I will be sure it can be a solution for our day to day production.

Regards
Valérian LEBERT


Imported from GitHub discussion by @vlebert on 2022-04-25T08:29:54Z

vlebert , have you read the storage documentation (Storage - QField Ecosystem Documentation) yet? If so, can you elaborate on the specific workflow(s) your company is having a hard time adapting? That’d be quite helpful in building an argument with Google to put QField in an arbitrary whitelist to regain full storage access (as some apps have already benefited from). Note that it is very likely that Google will sooner or later get rid of this full storage access whitelist for apps, which would bring us to the same point :slight_smile:

The “recent” shortcuts are merely shortcuts to projects you would have imported to begin with. If you are on Android >= 10, any lingering project shortcut that’s not referring to an imported project/dataset wouldn’t work.


Imported from GitHub comment by @nirvn on 2022-04-25T08:57:11Z

(vlebert , I’ve moved this into a slightly more appropriate discussion format)


Imported from GitHub comment by @nirvn on 2022-04-25T09:20:17Z

Hi,

regarding our workflow, we use 2 different method :

Method 1 :

  • We use Seafile (with Seadroid version <=2.25) for project “repository”. Tablets can download and update projects from here (direction master → user tablet)
  • We use Syncthing for uploading and consolidating field data (point layer + pictures) (direction tablets → master server)

Note : we had to block Seadroid to version 2.25 for the same reason (neweer version sync data in a private android folder somewhere lost in the filesystem)

From there we have routines on the server hosting Syncthing and Seafile to aggregate the data and export it in several ways (Postgis, etc.)

Method 2 :

  • We use termux, termux-api, termux-gui, GIT and customs scripts to act as a simple GUI allowing tablets to sync projects from master
  • Gitlab hosting (10Go per repo)
  • Master branch for project updates and 1 branch per tablet for field data and pictures upload (with resize within termux)

For french readers, I drafted an article aimed to be published on https://static.geotribu.fr/ (work inprogress)
Your connected workspace for wiki, docs & projects | Notion
There are more details inside

About the “recent” shortcut, I am surprised because I updated to new Qfield version without importing any project dans have a “recent” shortcut to an external project and seems fully functional (so no problem accessing full storage ?)

Valérian


Imported from GitHub comment by @vlebert on 2022-04-25T09:53:48Z

vlebert , on android <= 9, you would retain same storage access as before, maybe your device is older and runs on that version of android?


Imported from GitHub comment by @nirvn on 2022-04-25T09:55:54Z

Galaxy tab S4 / Android 10


Imported from GitHub comment by @vlebert on 2022-04-25T09:56:48Z

vlebert , feel free to attach a screencast if you want this further dissected :slight_smile:


Imported from GitHub comment by @nirvn on 2022-04-25T09:57:13Z

qfield

Does this replies to you need : no trace of imported project and still access to 1 recent project


Imported from GitHub comment by @vlebert on 2022-04-25T10:01:55Z

Where is this project located on your storage?


Imported from GitHub comment by @nirvn on 2022-04-25T10:03:29Z

Internal Storage/Seafile/


Imported from GitHub comment by @vlebert on 2022-04-25T10:04:26Z

vlebert , ah, can you check something for me: are you able to write to the datasets there, or merely read from it?


Imported from GitHub comment by @nirvn on 2022-04-25T10:22:57Z

Read-only indeed. Error when trying to write a feature


Imported from GitHub comment by @vlebert on 2022-04-25T10:58:04Z

vlebert , ok thanks, we should hide those upon upgrades to avoid confusion.

With the new export folder functionality added in 2.0.15 which allows you to copy the content of your project into a folder on your storage that’s accessible by seafile and synchthing, is the problem there that it adds and extra export step that’s too much of a burden to your field workers?


Imported from GitHub comment by @nirvn on 2022-04-25T12:55:36Z

Thanks for the advice, however I can’t imagine this solution to work for field workers.
Syncing must be quite transparent as these workers are not always very familiar with android etc.


Imported from GitHub comment by @vlebert on 2022-04-25T13:02:44Z

vlebert , fair enough. So you guys are setting up the services devices and provide them to field workers, some of whom might have limited knowledge on IT matters and can only be taught to enter data and not much else. Is that a fair representation?


Imported from GitHub comment by @nirvn on 2022-04-25T13:05:35Z

It is.
We provide some support with Teamviewer but it is quite painful.


Imported from GitHub comment by @vlebert on 2022-04-25T13:09:19Z

Thanks vlebert , helpful information.

One last question: would manual instalation of APKs will full storage access an acceptable solution for your team who set up the device prior to deployment? The downside would mean no auto update through the play store but in your case you might not want this to begin with to create a static environment while your field workers hold onto their devices.


Imported from GitHub comment by @nirvn on 2022-04-25T13:45:47Z

That’s what we do : manual install from release github page
Then set playstore autoupdate “no” for Qfield.

However, sometimes if you go to playstore and manually click to “all updates” then playstore will ingnore your preferences for specific app and update Qfield anyway.

Even if you install from APK, playstore will somehow link it to the official Qfield. Can this behaviour be changed?


Imported from GitHub comment by @vlebert on 2022-04-25T13:51:58Z

There are ways around avoiding this type of autoupdate.

Thanks for taking the time to provide detailed information on your workflow. We’ll look into what can be done.

In the meantime, I can’t stress enough of good a solution QFieldCloud might be for you, please take some time to explore it. It has to be the smoothest and most secure remote deployment there is for QField. There are nice users management (multi user project access and data push, user roles, etc.) features too that could make your workflows even better than before.


Imported from GitHub comment by @nirvn on 2022-04-25T14:03:49Z

Yes I will give a try because our current workflow is reaching its limits. But I am really concern about the “coming soon”. It’s been some years it’s coming soon :upside_down_face:

What is the current storage limit ? We produce tons of JPEG… And our current workflow allow us to resize JPEGs to lower res wich in not possible in Qfield and even in natives camera apps (samsung at least)…


Imported from GitHub comment by @vlebert on 2022-04-25T14:24:05Z