File Manager: switch to native syscalls to improve the speed on file operations

[0xlne]

Please check before submitting an issue

• I am using the latest version of App Manager
• I have searched the issues and haven't found anything relevant
• I have read the docs

Describe a description of the new feature

AFAIK, the File Manager module is currently relying on java routines for basic file operations (read/list/copy/move/delete).
The performance is subpar at best, & in my testing, extremely slow.
This has been tested - the same file operations on the same files copied over to a variety of phones - for comparison:
Red Magic 6
Galaxy Note 10+
Sony Xperia XZ2
Galaxy Z Fold 3
Xiaomi Mix Fold 2
The same testing protocol on other apps (Ghost Commander, Amaze, Axet's Files, Material Files) revealed no such issues.

Describe the solution you'd like

My suggestion is to implement file operations via native syscalls, which is much faster. IIRC, the latter from that list of apps has done exactly that.

Describe alternatives you've considered

Use other file managers as daily drivers.

Additional context

The FM is slowly maturing, but is only a faily addition to the arsenal of modules in the App Manager.
Basic operations are OK-ish, but cannot be relied on (yet) for speed in daily operations.
I have operations on folders with large, to extremely large number of files, which makes using the FM a no-go at the moment.
As a minimalist, I'd love to consolidate my arsenal of tools & have as much of this within 1 essential toolbox, being App Manager. On a sidenote, that would pertain to the terminal module as well, but that's another story.

[MuntashirAkon]

File operations are only slow because there's a 2 second pause between each operation. This is done to offer the users the ability to stop the process if it's done accidentally to reduce the loss of files. Similar is done by other FMs such as MiXplorer. But there's also a fast mode coming soon (I already have it available on my side but still testing). When this feature will be available, you'll be able to toggle between fast and slow mode with slow mode being the default.

Do not be deceived by the use of Java File API in App Manager. The API is used for convenience, but most functions of the API have already been replaced with syscalls (via android.system.Os).

---

As a minimalist, I'd love to consolidate my arsenal of tools & have as much of this within 1 essential toolbox, being App Manager.

In building App Manager, I've followed a strategy similar to rapid application development (as opposed to more professional alternatives such as agile which require a team work and highly boring methods), but over time, there were some modifications:

1. Like RAD model, App Manager focuses on features. Features are delivered to the users (technically, users mean customers in SDLC, not the actual users of the app, but in our case, users retain their actual meaning) as soon as they're implemented. But unlike RAD model, features aren't delivered to all users but only to those who're interested in testing them.
2. Like RAD model, coding in App Manager is done quite fast, but it does not use any generated code. Instead, it copies code from other similar projects (which are often best of their kind) or take hints from those (someone called it stitching which, I think, is exactly what it is).
3. Unlike RAD model, App Manager focuses on modularity, scalability, security and stability (in terms of features) which means App Manager frequently revises its internals without much affecting the externals (UI/UX). Features aren't just delivered to the users, they're properly planned and tested where the former gets more priority. A good planning automatically ensures more stability and less bugs. This also prevents dramatical or breaking changes in the future that you frequently see in other open source apps. This is also why certain features take longer to implement (eg. searching or APK editing).

Developing a massive GUI app such as App Manager requires a lot of time and efforts and is definitely not a single man's job (or worse, a hobby project). This is why strategies have been developed to ensure that I won't be bored, depressed or suffer a burnout which is why I work on features that I find interesting in that moment. Still, you can find features building up more rapidly than many other projects. For example, I started serious development in FM back in May and within August, you already get most of the features an FM has to offer (which would've been sooner if I didn't have that accident in June and had to rest for a month, which was a bit shocking as I couldn't attend my regular job to get paid).