search

Raival-e / File-Explorer-Compose

An Android file explorer written in Kotlin and Jetpack Compose
GNU General Public License v3.0
334 stars 14 forks source link

Add to F-Droid or IzzyOnDroid #7

Open GGORG0 opened 2 weeks ago

GGORG0 commented 2 weeks ago

Add the app to F-Droid or IzzyOnDroid to allow for better discoverability and auto updates.

By the way, awesome app! Thanks!

Raival-e commented 2 weeks ago

I'll soon...

I'm glad you liked it!

IzzySoft commented 2 weeks ago

@Raival-e we can continue our discussion here if you agree, no need for eMail in parallel :wink:

Pointer for the open question:

keytool -genkey -v -keystore keystore.jks -alias relkey -keyalg RSA -keysize 4096 \
  -sigalg SHA512withRSA -validity 10000 -dname "cn=Raival, c=OM"

You can of course use a different alias to your liking, and also specify your city (-l), organization (-o) and more in the -dname if you want; apart from that, the command should work as-is and generate you a proper keystore to be used for signing.

Raival-e commented 2 weeks ago

Done, hopefully it works this time :)

IzzySoft commented 2 weeks ago

Yes, that works now! A few questions still: what are android.permission.QUERY_ALL_PACKAGES and android.permission.ACCESS_NETWORK_STATE needed for? The other permissions I could explain. Further, what happens to https://github.com/Raival-e/File-Explorer – I see you have archived it? Shall we mark it deprecated at IzzyOnDroid, pointing to the new one, and removing it after a month or two (to give those having it installed a chance to switch)?

Next, I've checked if we can establish your app as Reproducible Build – but unfortunately, it's not reproducible. The Dex diff is huuuuge, never seen such a huge one (diff is 73 MB!). What are you using to build the APK? Looking at your code, hints are ambiguous:

neither of the two a "stable releases". The "next" stables would be 17 and 21. As your gradle says minimum 19, I've built with 21 (and we use OpenJDK here).

Would be great if this riddle can be solved and your app marked RB. Meanwhile, your app has been integrated and will become available here with the next sync around 7 pm UTC. Be welcome to pick a badge (and a shield if you wish) to link there from your Readme :smiley:

Raival-e commented 2 weeks ago

Thanks!

android.permission.QUERY_ALL_PACKAGES is needed to retrieve all apps that can open a certain file (currently used in "open with" dialog, it will also be used in the future as I'm planning to add a feature that will let the user extract apps that are installed in their devices).

As for android.permission.ACCESS_NETWORK_STATE, the app clearly doesn't use internet (as no such permission is declared in AndroidManifest.xml). I'm assuming, however, that one of the libraries used in this project requires it, although I'm not entirely sure which one does.

For the old File Explorer, this project is a replacement for that one, it has all the feature the old app has and more. It is no longer maintained, that's why I archived it. And yes, I think you can mark it as deprecated.

Lastly, I'm not entirely sure what you mean by "Dex diff", and where that 73MB difference came from. I'm using Android Studio, with Android Gradle plugin version 8.5.1 to build the project. Github workflow builds a debug version, and you're right, the versions do not match! and that's because I got the same android.yml from the old File Explorer, but never updated it. But i'll look into it soon.

IzzySoft commented 2 weeks ago 
git clone <repoURL> repo
cd repo
chmod +x gradlew
./gradlew assembleRelease
Raival-e commented 2 weeks ago

I'm sorry, but I'm not familiar with the command lines (I haven't used them before, all I do is to click "build" button in Android Studio). In the build settings however, the Gradle JDK is set to "JetBrains Runtime 17.0.11" (not sure if this is what you're looking for).

For the actions workflow, It used to create a release build (when I used to use a public keystore), but since I started using a private keystore (as you suggested), I've changed it to make debug builds instead (the workflow can't make a release build without providing the keystore). Github Action are often used to make a debug builds not a release ones (at least from what I've seen).

And the app in the release page was built and signed with Android Studio.

Zig-Rust-Odin commented 2 weeks ago

add to https://github.com/zapstore/zapstore

Permissionless app store powered by your social network

IzzySoft commented 2 weeks ago

all I do is to click "build" button in Android Studio

please make sure to click "clean" before that then for a release build, so old artifacts are not "staying in the way".

the Gradle JDK is set to "JetBrains Runtime 17.0.11"

That rings some bell. I'm no Android dev and never have seen Android Studio myself even; what alternatives does it offer there?

Raival-e commented 2 weeks ago

These are the options I have (and obviously I can download more).

IzzySoft commented 2 weeks ago

OK, then it was ringing the right bell. Can you see to download OpenJDK version 17.x and use that instead of JetBrains? At your convenience, OpenJDK version 21.x would also be possible (just let us know then which one you've picked; 17 is the default here, but we can also use 11 or 21 – the previous and the next LTS respectively). Please avoid versions 18-20 (and of course 12-16), those are no LTS versions. Thanks!

Raival-e commented 2 weeks ago

I don't understand why should I switch? JetBrains Runtime is the default and seems to be the optimal option for Android Studio.

IzzySoft commented 2 weeks ago

I don't understand why should I switch?

See above: reproducible builds. Might be worth a try to see whether the JDK is the culprit there. Could of course also be as simple as not having run clean before build. Your choice of course: RB is not mandatory at IzzyOnDroid – it's an additional security feature we offer.

Raival-e commented 2 weeks ago

So when you build the app yourself to check if it matches the release build I've published, you've found that the dex files do not match. is that right? If so, how would that be an issue if we now know that you used a different version of JDK than the one I'm using. I mean if you run the test again using the same version I'm using, wouldn't that be equal of me using the version you suggested?

I'm sorry for this looong thread, but I really don't know why is JetBrains JDK is suspected for a "bad act" here (not that I'm defending anything), Is it because the size difference you found? Isn't that expected since we both used different versions of JDK?

Raival-e commented 2 weeks ago

Another thing worth mentioning is that in Android Studio, I'm using baseline profile, which rearrange the classes between the dex files based on their usages in the app. I'm not sure whether this would take effect when using tools other than Android Studio to build the app.

IzzySoft commented 2 weeks ago

So when you build the app yourself to check if it matches the release build I've published, you've found that the dex files do not match. is that right?

Yes.

If so, how would that be an issue

Reproducible Build means it is byte identical – that using the same input (source), identical output (APK) is generated. In our automated builders, we have a set of options to choose from. As for JDK those are OpenJDK 11, 17 and 21. We cannot maintain a myriad of different options, sorry.

I really don't know why is JetBrains JDK is suspected for a "bad act" here

That's what we want to rule out. The goal is not for you having to change your entire setup – but to find out what causes the difference. And then to see how we can fix it. And it's less about the size, but about the number of differences: for RB there must be no difference at all. It either succeeds entirely, or it fails. Different versions of JDKs are sometimes causing that (among a number of other possible things; there's no complete list) – see e.g. here on differences with DEX.

And yeah, if the DEX differs, so do the baseline profiles. Sometimes they even differ without the DEX differing. Sometimes builds are "flaky" (non-deterministic), and 10 subsequent builds show 3 different results. But with such a huge DEX diff, that's a rather unlikely cause.

You can also take a look at our (just updated) hints on reproducible builds for some more background. Those are written for app developers – while the document linked above rather targets those running a "verification builder".