What is SAF?
SAF (Storage Access Framework) is google’s replacement for direct file access – the way how applications worked with files and folders before android 11. If application upgrades to compatibility with android 11 then it looses direct file access and must use SAF. There are special applications which google listed like a compatible with direct access, but emulators are not there. And it is disaster. However, at the end of the list is written that application which are broken too much can request direct file access. It must be manually granted by google. The solution what google provides is a unfortunate, because we really don’t need access to whole file system, but we need fast file access and this is available only with granted permission to ‘ALL FILES’.

So, why has Magic Dosbox so big problem with SAF?
Problem is in inconsistent performance. Before SAF were files and folders accessed very fast, it really helped to already performance sensitive emulator to be not laggy and without choppy sound. SAF communicates through IPC with some kind of process or daemon. This communication is slow, there are delays and the same file operation can be another time way slower then same operation few milliseconds before. This significantly increases loading times and makes emulation inconsistent. In the ancient DOS were problems with amount of RAM in computers, so programmers quickly created file, dumped data and returned them back with followed file deletion. This means, DOS programs constantly do something with files, not only at startup, but during runtime. This is the worst, it does not affect only loading times.

Another problem is how big differences are in execution times of each file operations. It varies per device, per android 11 update, per count of files on device and per who knows what. At 5th october I received new update for my Google Pixel 3XL. I ran storage test application before and after update. While file creation time stayed at the some performance, file deletion was doubled after update. Seems file deletion is pain in the ass and google has problems fix it, it constantly shows performance issues across tested devices with android 11.

Private folder
We can still use private folder. It is without restrictions at original performance. But, whole content is deleted when is application uninstalled. Google introduced flag “keepFragileData” which should prevent deletion by uninstallation. But whole concept of this flag is so stupidly made that I lost everything inside private folder several times during development. Copying something there and from is insanely slow, backuping takes ages. You will lost possibility sharing games with other emulators. Data are completely not safe inside this folder. If you are going try few games, it can be allright. If you have big collection then it is unusable.

Why is here this topic?
I hope, gathering enough information about saf performance can win for us access to direct file operations.

Test application
I created simple application for testing storage. It does 3 basic file operations executed on storage with direct files access and on SAF storage. It does:

• File create
• File open
• File delete

You can download it here. If you want test it, you must grant ‘all files’ as first step. This grants access and creates test folder ‘saftest’ in root of your storage (/storage/emulated/0/saftest). In next step, grant SAF permission the folder ‘saftest’. If are both permissions granted then you can test your storage performance. ‘File create’ creates file with unique name. ‘File open’ opens this file and adds there some text. ‘File delete’ deletes this file. You must do it step by step, else newly created file will have another name and file deletion does not recognize it. If you press file delete before file create then it crashes. It does not matter, it is a test.

Can I test SAF already now?
Magic Dosbox implements SAF since android 5, due access to sdcard. You can test it already now. Just create some folder on internal storage and instead sdcard, grant access on this folder.

What means these times in the table below for me?
Depends on emulated application or game. Deletion was cheap operation in DOS time and before android 11, now is not. For me is now hard to tell why dos application decided to rewrite file with “deleted file + create file” instead file truncate. But they did it this way. I tried several DOS editors for Pascal, Borland C, DosUAE or Fellow. All do it this way while editing text files. The games do the same for temp files, instead rewrite they delete it and create again, repeatedly. Realms of Arkania 3 creates and deletes more than 10 temp files in moment, uses them for a second and deletes them. This is done several times from the start to the first in-game scene. Both delete and file create are expensive operations in SAF.

Please, if you are on android 10 and higher, test your device and report result. I hope it will help.

Results from devices are below. First results are always slower. Probably SAF initializes something. First column is device name, next 3 columns are results using “ALL FILES” flag. The last 3 columns are gathered from SAF.

UPDATE 25.10.2021

I spend a lot of time on the SAF research and I discovered very strange things. I recorded it and created quick video. Is available here for download. Please note, is not finished, is rough and far from sleek, however it shows the SAF battlenecks. I just hurt my right arm, so things are slowered, sorry.

in addition, google fu…d important api and must be emulated while using SAF. With granted all files is not broken

https://issuetracker.google.com/issues/199091106

After watching the video above is clear that table above cant be linked to exact device, because SAF file performance depends a lot on count files on your device, every new file makes it slower.

But I need results from players, because I need arguments for google that magic dosbox cannot work effectively with SAF and is hurt by SAF too much.