All local projects and app folder contents emptied after 4.3.3 update — 10 days of unsynced field data lost (Android 13, Galaxy S20)

Ask the Community
1

QField 4.3.3, Android 13, Samsung Galaxy S20. Folder-based workflow — projects packaged with QFieldSync on the desktop, transferred and returned by USB cable. No QFieldCloud.

I used QField in the field on 17 September and captured data normally. QField updated overnight on 17–18 September. On the morning of the 18th I imported a new project from a folder and it imported without error. When I then tried to open the previous day’s project to continue the work, it was gone, along with every other project on the device.

Ten days of field data across roughly a dozen client properties, none of it synced back to the desktop. Last sync-back was 7 September.

Checked over USB from Windows at /Android/data/ch.opengis.qfield/files/ :

  • “Created Projects” — empty
  • “Imported Datasets” — empty
  • “Imported Projects” — contains only the project imported this morning
  • “QField” — contains auth, basemaps, fonts, logs, plugins and proj. All six folders exist. All six are empty.

So the directory structure survived and every piece of content inside it did not — including the logs, which leaves me nothing to diagnose from.

The app was not uninstalled or reinstalled. Storage was not cleared. Storage was not full. No cleanup utility was run. Single user profile, no work profile. There was a system update and restart earlier in the week, but the device worked normally in the field on the 17th afterwards.

Questions:

  1. Is this a known regression in 4.3.x? Has anyone else lost local projects after updating to 4.3.3?

  2. Did the resolution of the created/imported directory names change in 4.3.1–4.3.3? PR #7966 (translating the created projects and imported datasets/projects folder names) carries a “backport release-4_3” label and merged on 10 September, and there is a current thread here about project translations not being picked up when switching language. Could a change in how those folder names resolve cause the app to read from or write to different directories than the ones holding existing content — and would that account for the folder structure being recreated empty rather than the content being deleted?

  3. If the old content still exists on the device under different folder names, where should I look? I have full USB access to the app directory.

  4. Is there any recovery path at all from an Android device in this state, given the logs are also empty?

I have taken a full copy of ch.opengis.qfield off the device, the phone is in aeroplane mode, and nothing further has been written to it. Happy to provide anything useful.

2

@Nathan_Graminus , hey there, you’re the first one to report such an issue, let’s try to get to the bottom of this together.

To answer the questions in order:

  1. It’s not a known regression no.

  2. The localization of the directory names does not actually change the directory path. You can see here the localized name at the top with its actual path in the header:

image
image399×703 40.3 KB

  1. The content would all be in /Android/data/ch.opengis.qfield/files – that being said, there are two scenarios in which this could change. First, if the user had installed QField unstable from the play store (the icon is a black Q), the files would have been in /Android/data/ch.opengis.qfield_dev/files , that’s something worth checking. Also, if the phone has an external SD card, the files could have found their way there. Can we rule that out?

  2. I assume you were not distributing projects via QFieldCloud? Using that service would have created a “backup” living on the cloud. Otherwise, unless your phone is set up to auto-backup its content, there are not other recovery paths.

As I said, you’re the first person to report this, let’s investigate together. Awaiting reply on the points raised in answer #3.

3

Hi Mathieu,

Thank you for responding, taking this seriously and trying to help me solve this, I’d love to recover the lost data and projects, but am resigned to the fact it may not be possible!

Before the answers, something you should know: I’m an agronomist, not a developer. I’ve been using Claude AI to help me work out what happened, decide what was worth checking, and draft both my original post and this reply. So please spell out anything you’d like me to do — I’ll be following instructions rather than working from experience.

On point 3, the unstable build: my QField icon is the standard green Q, and there is no ch.opengis.qfield_dev folder on internal storage or on the SD card. Ruled out.

On point 3, the SD card: the phone does have one — 127 GB, exFAT. There is a ch.opengis.qfield folder in Android/data on it, but it is dated 30 October 2021 and has not been modified since. Inside it, files holds Pictures (empty) and QField containing auth, basemaps, fonts, logs and proj, all empty, with no plugins folder. So it looks like a dormant leftover from an old install rather than anything in current use.

To be thorough I also searched the whole card for *.gpkg and found nothing, then ran PhotoRec across the card’s unallocated space looking for deleted SQLite files. Zero results. I don’t think the card was ever involved.

For completeness on internal storage: Android/data/ch.opengis.qfield is dated 18/09/2026 7:06 AM, which is roughly when I imported the one project that morning, and nothing has touched it since.

On point 4: correct, no QFieldCloud — cable-based folder packaging with QFieldSync throughout, so no cloud copy. I’ve checked Google backups and there is nothing listed for this device. I accept the data is gone.

The phone has been in aeroplane mode and untouched since Friday morning, and the SD card is now out of it, so whatever state things are in is preserved if there’s anything further you’d like me to look at.

Three things I can’t explain, and you’re possibly the only person who can:

  1. What could empty the app’s own subfolders — auth, basemaps, fonts, logs, plugins, proj — while leaving the directory structure intact? The logs one puzzles me most. An app clearing its own logs seems an odd thing to happen by accident.
  2. Is there any code path in QField that removes directory contents — a migration, a cleanup on version upgrade, a move that could fail partway and leave the source deleted?
  3. QField uses Sentry. If my device sent any crash or error telemetry around 17–18 September, would that be visible to you? Since my local logs are empty, that may be the only diagnostic record that exists.

Happy to run anything else you’d like checked while the device is in this state.

4

Hello Nathan,

To get a slightly better picture:
What would have been visible in Created project, Imported Datasets and Imported Projects?
How many projects were stored on the device? Do the project names differ, just to rule out the possibility of accidentally overwriting the project from the day before?

5

Hi Jeroen,

Created Projects empty, Imported datasets empty and imported projects held 63 projects, all unique file names (farm names).

I was using QField on Thursday, I was recording notes in a layer called PdkNotes and Lines on a layer called SoilTransects, both gpkg layers.

An automatic update took place Thursday night/Friday morning. I returned to the field Friday morning to find my Imported Projects folder empty.

I have stopped using the S20 and now using iPhone 15Pro in the hope I can recover my data from the S20, but that is looking less and less likely as I did not have a backup of the phone.

Thank you for reaching out, I hope you have something that can help me.

EDIT:

One other thing that rules out an overwrite: it wasn’t only the projects. The app’s own subfolders were emptied too — auth, basemaps, fonts, logs, plugins and proj all still exist under Android/data/ch.opengis.qfield/files/QField, and all six are empty. Importing a project can’t empty the app’s plugin or authentication folders, and it certainly can’t clear its own logs. Whatever happened reached well beyond the project directories.

To correct one detail from my last post: Imported Projects wasn’t completely empty on Friday morning. It held the one project I’d imported a few hours earlier, which imported normally and without error. Everything else was gone.

Cheers

Nath

6

@Nathan_Graminus , this sounds like something might have happened at the OS / device level. I cannot think of a code path that would be triggered on update and result in wiping of all project and non-project data within the /data/ch.opengis.qfield/files/QField folder.

I feel your pain, data loss is always a bummer :confused:

7

Could a new profile somehow have something to do with this? That somehow somewhere a profile has been reset? Is that even a thing when only using cable export?

8

Jeroen — no, I don’t think a profile explains it. The phone has a single user, no additional profiles have ever been set up, and Secure Folder has never been used. Nothing prompted me to set anything up or sign in again.

Mathieu — before I accept this as a device-level mystery, there’s one thing I’ve found that I can’t explain, and you’ll know straight away whether it matters.

Settings → Apps → QField → Storage on the S20 currently reports:

  • App: 343 MB
  • Data: 151 MB
  • Cache: 1.40 GB
  • Total: 1.89 GB

Meanwhile Android/data/ch.opengis.qfield/files/ holds Created Projects (empty), Imported Datasets (empty), Imported Projects (one project, imported the morning I found the problem), and QField containing auth, basemaps, fonts, logs, plugins and proj, all empty. There is no cache folder at that level, so I assume the 1.4 GB is in the app’s private internal directory, which I can’t reach without rooting.

Is 1.4 GB of cache normal for QField? If that’s ordinary Qt and tile caching then I’ll accept the data is gone and stop chasing it. If it isn’t normal, it’s the only unexplained thing left on the device, and I’d rather ask than assume.

For completeness, the SD card is now conclusively ruled out. Its ch.opengis.qfield folder is dated 30 October 2021 and hasn’t been touched since — a leftover from an old install. I searched the whole card for *.gpkg and found nothing, then ran PhotoRec across its unallocated space for deleted SQLite files and got zero results.

The phone is still in aeroplane mode, untouched apart from these checks, at 69% storage so nothing is being reclaimed. I’ll leave it that way until you’ve had a look at the numbers above.

9

Hi @Nathan_Graminus ,
that is a very thorough inspection and good observations.
I am not associated with the QField devs and have no word in this. And I am not remotely a phone expert.
However, because I do not go on fieldwork myself and just distribute projects, I could wipe my QField and re-install it (Lineage 23.2 on Fairphone 5; installed directly from github release via “obtainium”).

Observation: Cache is zero on fresh install; first startup initialization with the default test projects bumps this to 4MB. Not remotely close to the 1.4GB.

Screenshot (Sep 25, 2026 9_48_14 PM)
Screenshot (Sep 25, 2026 9_48_14 PM)1224×2700 101 KB

Just an observation. Implication is twofold, I think. (i) A fresh install really wipes the project folders. (ii) “Virgin” QField uses much less cache than on your device.
Hopefully others can figure whether it is possible and how to get to that hidden gigabyte!

10

Hi Falk — thank you, that’s a genuinely useful baseline and I appreciate you wiping your install to get it.

The comparison holds up well: your app size is 341 MB against my 343 MB, so we’re looking at the same build with the same footprint. Against that:

  • Cache: yours 3.97 MB, mine 1.40 GB
  • User data: yours 25.44 MB, mine 151 MB

I should be fair about one thing — my install is years old and has had 63 projects through it, where yours is minutes old. Caches grow, so some difference is expected.

But the user data figure is the one I can’t explain. My visible files folder holds a single project of about 5 MB and nothing else. Yours, with the bundled sample projects, reports 25 MB. Mine reports 151 MB. That leaves roughly 145 MB of user data somewhere I can’t see.

So my question to anyone who knows the codebase: is there any way to enumerate what’s in those directories from inside the app? QField has a plugin framework — would a small QML plugin be able to list the cache and data directories and report file names and sizes? If that’s feasible, I have the device sitting untouched in aeroplane mode and I’m happy to install one and report back.

I’m not expecting my data back at this point. But if there’s a gigabyte and a half of something unaccounted for in a field app, that seems worth understanding regardless of whether it helps me.

Thanks

Nath

11

@Nathan_Graminus , the largest chunk of data filling the cache would be tiles from XYZ raster/vector tiles. If your projects make use of eg an openstreetmap layer or a Google/bong satellite layer, after months of use it’d grow up into a large cache.

The cache allows for faster layer rendering and rendering of already fetched tiles in offline environment so it’s quite useful.

However your projects wouldn’t have been transferred into that part of the storage. Good of you to want to rule that out though.

12

I do not know whether there is a way to search these directories from inside QField (it is not a file browser). What I would use to really see all the files in there is to use the android debug bridge (adb). For that, you would have to (1) install some version of the adb command line interface on your host computer’s operating system, (2) enable “developer options” and “usb debugging” on the phone, (3) connect the mobile via usb.
With that, you have a lot of control, for example:

  • list devices and connect with adb devices (requires confirmation on first contact)

  • list what is in the QField subdirectories, e.g. “Imported Projects”, with[^1]:
    adb shell "ls -lisa /storage/emulated/0/Android/data/ch.opengis.qfield/files/Imported\ Projects/"

  • optionally “pull” everything you have in there (i.e. copy it to host) with
    adb pull "/storage/emulated/0/Android/data/ch.opengis.qfield"

  • Note that your Android/data folder might be in a different place; then just start from the root directory adb shell "ls /" and navigate through the directory tree from there.

  • Best adb disconnect once you are done to safely close the debug bridge.

If it is not visible via the command line, it is not there.
Caveat: I do not know where the cache is stored. It should be somewhere on the device and accessible. Makes sense though what @Mathieu_Pellerin writes that the cache are offline tiles, and unrelated to your project data.

[^1]: structure of that command:

  • adb invokes the android debug bridge.
  • adb shell "..." means you execute commands on the android shell, which is like a little, limited linux shell. The command in quotes is the command you execute; the output will be displayed on your host machine (though effects such as copying or removing are happening on the mobile, of course).
  • The command here is ls for “list files”, and -lisa are parameters for l = list, i = with index number, s = show size of the files, a = all files including hidden files.
13

Falk — thank you, that worked exactly as you described. I’d never used adb before and your instructions were clear enough that I got there without trouble. Here’s what it found.

As with my earlier posts, I should say that I’ve had Claude AI helping me work through this — deciding what was worth checking, interpreting the output, and drafting these replies. I’m an agronomist, not a developer. The observations are from my device; the framing of them isn’t all mine.

The app’s external directory contains one entry and nothing else:

drwxrwx--x 3 u0_a343 sdcard_rw 3488 2026-09-18 07:06 .
drwxrwx--x 6 u0_a343 sdcard_rw 3488 2026-09-18 07:06 files

No cache folder. So Windows wasn’t hiding anything — what I could see over USB was all there was.

du -sh on the whole directory returns 6.3M, against the 1.89 GB that Settings reports for the app. ls -la /data/data/ch.opengis.qfield/ returns permission denied, so the remaining ~1.88 GB is in the app’s private internal storage and unreachable without rooting. That’s consistent with Mathieu’s explanation that it’s offline tiles, and I’m treating the question as settled.

One small correction, offered helpfully rather than otherwise. Your line “if it is not visible via the command line, it is not there” holds for external storage, but not for the private internal directory — adb shell runs as the shell user and can’t read /data/data/<package>/ on an unrooted device. run-as only works on debuggable builds, and adb backup stopped including app data at Android 12. So adb reaches everything in external storage and nothing in the internal cache. Worth knowing for anyone who follows this thread expecting a complete answer from it.

The finding I think matters most for anyone this happens to next:

Every directory in the tree — files, Created Projects, Imported Datasets, QField, and all of auth, basemaps, fonts, logs, plugins, proj — carries an identical timestamp of 2026-09-18 07:06. That is QField launching that morning, finding its structure gone, and recreating the whole thing empty.

Which means the app’s own first launch destroyed the filesystem evidence of when the loss occurred. I opened QField and imported a project before I knew anything was wrong, and in doing so I wiped the timestamps that might have told you something.

So if another user reports this: tell them not to open QField before the device is examined. That’s the one thing I’d do differently, and it cost whatever diagnostic value the device had.

My data is gone and I’ve accepted that. Ten days across about a dozen client properties — the soil samples themselves were all collected and labelled, so what I lost was the field notes and transect geometry rather than the sampling work itself. I’ve since moved to an iPhone, turned off automatic app updates on the field device, and changed my routine to export the project at the farm gate before I leave each property rather than syncing when I next get around to it. Three days of exposure became zero.

I’d suggest leaving this thread open rather than marking it resolved. Nothing here identifies a cause, and if someone else hits it the detail in this thread may be the only starting point they have.

Thanks again to you, Mathieu and Jeroen for taking it seriously.

Cheers
Nath

14

I’ll be honest I haven’t read every bit of this discussion, Claude can get quite wordy and also be prone to going down rabbit holes and hallucinating things sometimes making things seem worse than they are.

I did have a similar issue recently where Qfield updated and then I got a call from a panicked surveyor thinking they had lost yesterdays data, it was still there and we found it ok.

15

interesting @BTreeTech ! Do you remember what made the surveyor think he lost the data? And were did you end up finding it? There seems to be quite a few accounts of “missing data”, I think the details of your story can be really useful to other people in a similar situation.

16

Sadly I don’t have details as I was on on the side of a hill at the time… from memory when they opened Qfield they saw the new version message then they didn’t end up on the main map screen like they were expecting and I think the project didn’t show up on the recently used list on the home screen - I believe we checked it was all there in ‘files -on the iPad’ then browsed to it in Qfield and re-opened it and all was fine.

17

Consider yourselves lucky. I lost all my data. All folders where there and all were empty. Every imported project gone.

18

Thanks Cuprico. I’m after help, although resigned to the fact the data is gone and unable to be retrieved. If somebody has a solution as to how or why this happened so it doesn’t happen to anybody else that is a good outcome.

19

Our surveyors normally zip up their data and share it to teams at the end of each day, either to get processed or just as a backup. It’s not as elegant as Qfield cloud but it’s much easier for non specialists to see and understand what’s going on with their files.

20

Thank you, that’s what I have been doing since I lost the data. I’m actually finding the process better than waiting for a group batch to do via cable transfer and the data is safe in multiple locations!