Table of Contents
It’s been a while since our last post and with the current update to RCX
1.12.2, we think an update about the general state of the project is in order.
Thoughts on AAB packaging
Starting in August 2021, new apps can only be published as an AAB package to Google Play. AAB is a successor to split APKs and allows Google to create APKs that only contain the required resources for target devices. Unfortunately, the way Google has implemented AAB means that developers need to hand over their signing keys to Google. As explained by Mark Murphy, this raises some uncomfortable questions.
For RCX, we will continue to use the old approach. That means distributing split APKs, even if that causes some effort when building the app. APKs distributed through Google Play or GitHub will continue to be signed with our own key. F-Droid APKs are built and signed by F-Droid.
Newer Android versions
Every year brings a new Android version, and a scramble to figure out what the new restrictions are and how much we are affected by them. After the scoped storage issue in Android 10 (API 29), Android 11 (API 30) actually brought some improvement in the form of a new permission:
MANAGE_EXTERNAL_STORAGE. Apps with certain use cases, like file managers, encryption utilities or backup tools can now (as of May 2021) apply for a Google Play exception to request this permission.
But what exactly does this do? Basically, it allows RCX to actually work as a file manager. Without this permission, apps cannot (directly) access any storage other than their own. Hardly useful for a file manager. We have applied for an exception and have passed the review for an internal release. Of course, as it is always the case with Google Play, you never know when they will change their mind.
If you open RCX for the first time, you will now be asked to grant RCX this permission. You will be redirected to the system dialog, where you have to flip the switch yourself. You don’t have to enable this permission for RCX, but without it, you cannot really interact with the local file system. That means no uploads or downloads, though you can still open files and stream media files.
If you already completed the question on a previous Android or RCX version, you can also manually change this by going to Settings > File Access > Grant MANAGE_EXTERNAL_STORAGE and then enabling access.
Older Android versions
Since we publish RCX, we have added two new supported Android versions, 10 and 11, and 12 will follow as the year progresses. At the moment, 89% of our users are on Android 10 or newer. We have already announced on the issue tracker that we’re going to drop Android 5, 5.1 and 6. RCX
1.13 will be the first version where Android 7 (API 24) is required. RCX on Android 5-6 may continue to see a few updates to update the internal rclone binary and (if reasonable) backports of bug fixes.
Migration to Microsoft Appcenter
As detailled in a previous post, we have switched to Microsoft Appcenter for error reporting. Initially, there were some concerns that this switch from Google Firebase would result in less useful data. However, the migration turned out to be a major success. In version
1.12, the first with Appcenter, we managed to track down and fix more errors than in any previous version. We would like to thank our users for contributing error reports, it really helps us out.
You can find out more about which data items are collected on our privacy page. We will soon update this page to include more information about when data is sent and how our error investigation process works. Also, we will add information about Google manged services like Google Mobile Services and the Play Store.
The curious case of weird ABIs
Apart from all the usual error reports, we also received quite a few reports with truly weird errors. All of these reports indicated severe malfunctions when RCX was trying to locate or run the internal rclone binary. Generally, this should not happen since the Android PackageInstaller is supposed to refuse installation if the APK is not compatible with the device.
Further weirdness was indicated by the reported phone model and brand. The reports contained the names of popular phone models, which are compatible with the installed RCX/rclone version and should therefore never experience this kind of issue. In-depth analysis of the reports revealed that all those devices are actually Intel x86 based TV boxes. These boxes claim to support ARM64 or AMD64, but then fail to properly emulate the claimed architecture.
Note that you can definitely run RCX on x86 hardware. However, you may have to manually download the x86 APK from GitHub if your device claims to support ARM64 (and then receives a ARM64 APK from an app store) but does not actually support the claimed architecture.
Apart from the already described topics, we are also working on:
- Our support for the Storage Access Framework, both as a client and as a Content Provider. Both are available as preview features and are progressing to a state where we will feel comfortable to enable them by default.
- After starting with German in 1.12, we will continue to work on supporting more translations.
- At-rest encryption is currently being tested and we plan to allow opt-in in a future version.
- Progressing on maintenance tasks:
- Enabling view binding.
- Migrating AsyncTask etc. to RxJava.
- Rclone as library.
- Improving the documentation. We want to improve the quality and depth of our docs and plan to migrate them to git, enabling everyone to contribute.
- And a lot of other things.
That’s it for this update. If you have some time to help us out, take a look at our new CONTRIBUTING.md. We really appreciate all of our contributors ❤.