Currently Amaze is disabled on fdroid for the reason that it's using a few proprietary libraries. This issue is focused at providing an alternative / removing those libraries so that fdroid servers can build Amaze File Manager

This now has a bounty, here.

Please claim after a PR fixing this issue is accepted. Remember that you can also back the issue adding to the bounty!

App isn't fully capable of the scoped storage API calls for accessing said directory as a file manager.

• Device: Pixel 3a
• OS: Android 11
• Rooted: No
• Version: 3.5.0

I can't access files saved with apps like Telegram which store downloads in such a location. They don't even show up as recent files in anything else but the built-in file manager in Android (not google files, I have that disabled)

There should be a n actual API call specifically for file managers to access that location but as I'm not completely savvy on the inner workings of modern Android APIs I don't exactly know what it's called. This should probably be looked into heavily when building for Android 11 since the scoped storage API is mandatory now, and it should be seamless to Android 10 users already using the app.

I try to organize my images with Amaze. Therefore I go into the folder containing the images shot with OpenCamera, which is on my SD card "Pictures/Open Camera" and I create some folders and sort images into them.

Steps to reproduce the behaviour:

1. Go to /storage/[cardID]Pictures/OpenCamera, create a folder
2. Select some images
3. Since there is no "move" feature, click on the scissors icon
4. Enter the folder just created and click on the clipboard icon
5. Watch and see images appear every 10-20 seconds at a time
6. Go the the parent folder again and see images disappear 10-20 seconds at a time
7. Connect the phone to a PC and look into the Pictures/OpenCamera folder
8. Try to find the folder created in 1). Nowhere to be found!
9. Go into Amaze again, re-enter the folder, it is still there.
10. Look at the images cut in 3): They are gone (the expected result)
11. Check with the PC: there they are gone, too (expected). Again try to find the folder (nowhere, and that is unexpected).

Expected behaviour: Cutting and pasting should be executed immediately, not in ultra slow-motion. And folders created and populated in Amaze should be seen via USB on the card... Results of these operations should be noticeable on the storage media...

• Device: Fairphone 2
• OS: Fairphone Open OS 19.11.2 (Android Nougat 7.1.2)
• Rooted: No and Yes (not necessary on FPOS)
• Version: 3.3.2
• SD card: Sandisk Ultra 128 GByte SDXC SDSQUAR-128G-GN6IA, the one sold as “up to 100 MB/Sec, Class 10, U1". Card is very fast, as can be seen via USB...

First, the speed cannot be explained. It is many orders of magnitude (!) slower as could be expected, second, it seems that cut & copy is not operated on the OS level (where no data at all would be moved, just the pointer in the file system modified) but actual data are transmitted. But even that doesn't explain this level of slowness.

Where exactly are my images now? According to the PC, the are no longer in the OpenCamera folder. But since the newly created folder is missing, the images can't be there. But Amaze still shows them, so they must be somewhere. Does Amaze create temporary folders somewhere?

Exactly where are my images? I want to backup them to the PC...

I have Amaze installed on an HP Slate Plus, which is an older 7" tablet with a 1.3ghz quad core nVidia Tegra CPU, 1280x800 screen, 1GB RAM and 8GB flash, running 4.2 Jellybean.

I can make Amaze crash reliably by going the Settings and tapping on About Amaze File Manager.

I can also make Amaze crash by tapping on a file in an Amaze directory listing. The dialog box asking what I want to use to view the file comes up, but Amaze goes away.

I don't recall this behavior in the 3.00 release. I have that on another tablet running 5.01 Lollipop, and cannot reproduce the crashes there. This may be Android version dependent.

Description

• Refactored SshConnectionPool to more generic NetCopyClientConnectionPool
• Change SshClientTemplate to NetCopyClientTemplate
• Implement FTP client support. Defaults to passive FTP and implicit SSL for FTPS
• Add optional thread safety to NetCopyClientConnectionPool on executing NetCopyClientTemplate, as Apache FTPClient is not thread safe. This shall bring deadlocks when connecting to FTP servers, but let's see...
• Migrated GetSshHostFingerprintTask and SshAuthenticationTaskCallable to callable and RxJava, in align with FTP client implementation
• Downgrade Apache FTP server to 1.1.1, as problems found with enabling TLS at Amaze FTP server after previous upgrade to 1.1.4

Issue tracker

Fixes #1570

Automatic tests

• [x] Added test cases

Manual tests

• [x] Done

Tested on Pixel 2 emulator running Android 11, against Amaze FTP server running on Oneplus 2 running Lineage OS 18.1 (11).

Build tasks success

Successfully running following tasks on local:

• [x] ./gradlew assembledebug
• [x] ./gradlew spotlessCheck

Fixes #138, fixes #163, and brings #1222 back.

As said, this is a greedy PR ;)

Changes:

• Backport of commons-compress 7zip support (as separate module) to use FileChannel only, instead of SeekableByteChannel which exists only after Android 8
• Brings #1222 back - last attempt failed due to huge difference between PR and master, so let's try again ;)
• Uses zip4j instead of java.util.zip package, in order to provide support of password-protected zip files
• Refactored GeneralDialogCreation.showDecryptDialog() to allow entering archive password uses the same prompt dialog

Not going to think why the previous work by @N00byKing ran without problems - it is possibly caused by upgrading commons-compress library... but anyway.

Tested on Oneplus 2 running Slim7 (7.1.2). Crashed on GPD XD running LegacyRom (4.4.4), but it's because of another problem: API < 21 does not support vector drawables.

03-16 21:49:21.940 2864-2864/com.amaze.filemanager.debug E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.amaze.filemanager.debug, PID: 2864
    java.lang.RuntimeException: Unable to start service com.amaze.filemanager.asynchronous.services.ExtractService@41d8cbf0 with Intent { cmp=com.amaze.filemanager.debug/com.amaze.filemanager.asynchronous.services.ExtractService (has extras) }: android.content.res.Resources$NotFoundException: File res/drawable/ic_zip_box_grey.xml from drawable resource ID #0x7f0800e8
        at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2705)
        at android.app.ActivityThread.access$2100(ActivityThread.java:135)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1293)
        at android.os.Handler.dispatchMessage(Handler.java:102)
        at android.os.Looper.loop(Looper.java:136)
        at android.app.ActivityThread.main(ActivityThread.java:5001)
        at java.lang.reflect.Method.invokeNative(Native Method)
        at java.lang.reflect.Method.invoke(Method.java:515)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:811)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:627)
        at dalvik.system.NativeStart.main(Native Method)
     Caused by: android.content.res.Resources$NotFoundException: File res/drawable/ic_zip_box_grey.xml from drawable resource ID #0x7f0800e8
        at android.content.res.Resources.loadDrawable(Resources.java:2096)
        at android.content.res.Resources.getDrawable(Resources.java:700)
        at android.support.v4.app.NotificationCompat$Style.createColoredBitmap(NotificationCompat.java:1893)
        at android.support.v4.app.NotificationCompat$Style.createColoredBitmap(NotificationCompat.java:1889)
        at android.support.v4.app.NotificationCompat$Style.applyStandardTemplate(NotificationCompat.java:1805)
        at android.support.v4.app.NotificationCompat$DecoratedCustomViewStyle.createRemoteViews(NotificationCompat.java:3007)
        at android.support.v4.app.NotificationCompat$DecoratedCustomViewStyle.makeContentView(NotificationCompat.java:2963)
        at android.support.v4.app.NotificationCompatBuilder.build(NotificationCompatBuilder.java:222)
        at android.support.v4.app.NotificationCompat$Builder.build(NotificationCompat.java:1585)
        at com.amaze.filemanager.asynchronous.services.ExtractService.onStartCommand(ExtractService.java:129)
        at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2688)
        at android.app.ActivityThread.access$2100(ActivityThread.java:135) 
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1293) 
        at android.os.Handler.dispatchMessage(Handler.java:102) 
        at android.os.Looper.loop(Looper.java:136) 
        at android.app.ActivityThread.main(ActivityThread.java:5001) 
        at java.lang.reflect.Method.invokeNative(Native Method) 
        at java.lang.reflect.Method.invoke(Method.java:515) 
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:811) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:627) 
        at dalvik.system.NativeStart.main(Native Method) 
     Caused by: org.xmlpull.v1.XmlPullParserException: Binary XML file line #1: invalid drawable tag vector
        at android.graphics.drawable.Drawable.createFromXmlInner(Drawable.java:933)
        at android.graphics.drawable.Drawable.createFromXml(Drawable.java:877)
        at android.content.res.Resources.loadDrawable(Resources.java:2092)
        at android.content.res.Resources.getDrawable(Resources.java:700) 
        at android.support.v4.app.NotificationCompat$Style.createColoredBitmap(NotificationCompat.java:1893) 
        at android.support.v4.app.NotificationCompat$Style.createColoredBitmap(NotificationCompat.java:1889) 
        at android.support.v4.app.NotificationCompat$Style.applyStandardTemplate(NotificationCompat.java:1805) 
        at android.support.v4.app.NotificationCompat$DecoratedCustomViewStyle.createRemoteViews(NotificationCompat.java:3007) 
        at android.support.v4.app.NotificationCompat$DecoratedCustomViewStyle.makeContentView(NotificationCompat.java:2963) 
        at android.support.v4.app.NotificationCompatBuilder.build(NotificationCompatBuilder.java:222) 
        at android.support.v4.app.NotificationCompat$Builder.build(NotificationCompat.java:1585) 
        at com.amaze.filemanager.asynchronous.services.ExtractService.onStartCommand(ExtractService.java:129) 
        at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2688) 
        at android.app.ActivityThread.access$2100(ActivityThread.java:135) 
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1293) 
        at android.os.Handler.dispatchMessage(Handler.java:102) 
        at android.os.Looper.loop(Looper.java:136) 
        at android.app.ActivityThread.main(ActivityThread.java:5001) 
        at java.lang.reflect.Method.invokeNative(Native Method) 
        at java.lang.reflect.Method.invoke(Method.java:515) 
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:811) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:627) 
        at dalvik.system.NativeStart.main(Native Method) 

Some further changes necessary, so I'm putting a do not merge label here, until the following are fixed

• Fix crash on Android 4.4
• Fix unit tests which should fail

However, please do take a look at the implementation first.

This is in response to #498.

Before going further, some disclaimer:

• For the purists: I was born as Java developer with dedication to server-side stuff (my past jobs were mainly work with Spring Framework (up to 3.0 though)), so my programming patterns may not be compatible with Android's, as well as some decisions I made may not be correct or appropriate
• I rely heavily on Android's API and Android Studio's feedbacks to tell me I was doing things wrong. I may have missed something I don't know about with Android
• My work was started on 3.1.2RC4 codebase, I may not have take advantage of some Java8 features available to Android (e.g. Lambdas which I saw on some code during merge)
• For the same reason, as well as I didn't merge with upstream from time to time, I may have missed some API changes on master. I'd say I did my best to make the merge, but I may still missed something
• I used the current SMB client's behaviour as reference, may become the cause of some unexpected behaviours in my implementation
• Sorry about the number of commits I made - I used small commits to track what did I do with the code, as well as I was working on different machines on implementing it
• Both SFTP and SSH are used in code and comments, they mean the same thing

Then, couple of change warnings before this pull request is even opened:

• To deal with SSH keys(public/private, client/server sides) properly - SpongyCastle is used instead of Android's stock BouncyCastle (which was already long outdated). Therefore the resulting APK had hit Dalvik's 65k method limit and multidex had been enabled. The last time I build the master the APK was around 57k, so I think it's a matter of time hit the limit anyway
• Because of the way I wrote my SSH client implementation to reduce complexity and coupling, I used AppConfig to access UtilsHandler and MainActivity's Context

Now back to the pull request.

As said in #498, my implementation was an integration with sshj which I saw it as simpler and a better alternative than jsch.

The connection setup dialog was basically a rip-off from SmbConnectDialog ;) couldn't find an icon handy, so I used the Tux icon to represent SSH servers.

It supports both password and key authentication. I tested it against my Ubuntu Xenial machines (home desktop and VMs) on Lollipop and Nougat emulators.

Upload, download, mkdir, delete, rename should be working properly.

Now let the cruel code review begin... wish me luck.

I changed every java file that had com.amaze.filemanager to my own package id but in this file I get a error with these 2 imports and I'm not sure how to fix it. I'm new to Android coding and I've been using open source projects like this to try & learn any help I get is greatly appreciated.

import com.amaze.filemanager.IMyAidlInterface;
import com.amaze.filemanager.Loadlistener;
import com.stericson.RootTools.RootTools;

Closes #163

Background:

I wanted an open-source File Manager. Found this one, seemed nice. OH NOES! IT DOES NOT SUPPORT MY FAVOURITE ARCHIVE FORMAT (7z)! Good thing I know some ʳᵉᵃᶫᶫʸ, ʳᵉᵃᶫᶫʸ ᵇᵃᵈ Java and it's open-source after all!

Implementation:

• One added Dependency: XZ for Java. Commons-Compress requires XZ for Java for 7zip (http://commons.apache.org/proper/commons-compress/limitations.html)

• Add 7z extension to RecyclerAdapter, CompressedHelper and MimeTypes

• Implements SevenZipHelperTask, SevenZipExtractor, SevenZipDecompressor

• SevenZipHelperTask is pretty much copy-pasted from Gzip and rebranded

• SevenZipExtractor is not as good as could be, I admit. It does is job though. One problem: It doesn't buffer, as I couldn't find a way to do it with commons-compress

• SevenZipDecompressor is also copy-pasted from Gzip, rebranded

This is probably my first and last meaningful addition here, cuz I really don't know that much about file managers :P

Sorry for it being this bad, just wanted some 7z support.

And lastly, thank you for making this app!

P.S. "7zip types", as 7zip archives can use different compression algorithms

Remake of #916 which was halted due to change in codebase and conflicts with master.

The following filename will make the app crash when it tries to display the filename (in "list" view only -"grid" view works ok):

M2345 123 1234567890x1234567890 123 12.mp4

Substituting a "space" for the "x" character near the middle of the filename prevents the crash. The app then simply shows the whole "words" that it can and truncates the rest. The following filename also does not cause the app to crash:

M234567 1234 123456789 12- 12 12345678901.mp4

Nor does an equally long filename with no spaces in it (the app "abridges" the filename, inserting "..." in the middle). So it seems to be something to do with the length of the different parts of the filename and where the app decides to truncate or abridge it.

Different behaviour is evident whether the phone (and therefore the app window) is in "portrait" or "landscape" mode (i.e. one filename will crash the app in portrait but not landscape, and vice versa for a different filename), so it seems related to display area.

(Amaze v3.2.1, Lollipop 5.0.1, Huawei P8, 1080x1920 display).

Description

I think it's about time to put this through... also for #3318 and #2988 to proceed, be it within the 4.x cycle.

Not removing the pre-4.4 logic within the code for now - can do on your call.

Issue tracker

Fixes #3189

Automatic tests

• [ ] Added test cases

Manual tests

• [x] Done

On Galaxy Nexus emulator running Android 4.3, Amaze no longer installs. But on Galaxy Nexus emulator running Android 4.4, Amaze still installs and runs.

Build tasks success

Successfully running following tasks on local:

• [x] ./gradlew assembledebug
• [x] ./gradlew spotlessCheck

Description Multiple spaces in filenames in directories that require ROOT access are displayed as just one space

To Reproduce When I use other file managers to create a file named a b folder, a b will be displayed on Amaze (multiple spaces become one space). When I create a b in other file managers, a b will also be displayed on Amaze. Then it will cause that files with the same name will be displayed on Amaze, but in fact their names are different.

Screenshots

Reason of This Problem String[] array = line.split(" +"); in the parseName function in com.amaze.filemanager.filesystem.files.FileUtils treats all multiple spaces as one space

Solution Improved parsing scheme

Description

• Migrate FragmentStatePagerAdapter in TabFragment to FragmentStateAdapter
• Consequently, remove incompatible DisablableViewPager to ViewPager2
• Consequently, migrate incompatible OnPageChangeListener implementations to ViewPager2.OnPageChangeCallback, which is not interface and needs to be subclassed

Too bad Android X's test framework doesn't support custom Activities... so for test cases, either

• further refactorings at TabFragment to decouple from MainActivity
• use Espresso test, but will raise app's minimal supported version to 4.4 (#3189)

Issue tracker

Fixes #2790

Automatic tests

• [ ] Added test cases

Manual tests

• [x] Done

• Device: LG Nexus 5x

• OS: LineageOS 17.1 (Android 10)

Build tasks success

Successfully running following tasks on local:

• [x] ./gradlew assembledebug
• [x] ./gradlew spotlessCheck

Description

Issue tracker

Fixes #3638 Fixes #3666 Fixes #3673

Automatic tests

• [ ] Added test cases

Manual tests

• [x] Done

• Device: Pixel 3A Emulator

• OS: Android Tiramisu - API 33

Build tasks success

Successfully running following tasks on local:

• [x] ./gradlew assembledebug
• [x] ./gradlew spotlessCheck

Is your feature request related to a problem? Please describe. It is very hard to determine whether a copy, move, et cetera operation has completed.

Describe the solution you'd like A small progress bar near the bottom if the screen, maybe as a part of the copy dialogue.

Describe alternatives you've considered A notification with a progress bar, so you can use other apps and check up on the progress.

Additional context —