License question

[IzzySoft]

This sounds like a real interesting app! May I ask if it is F/LOSS – and if so, what license it falls under? You have no license declared currently, so this is unclear.

[monsiu]

Thanks for the nice comment!

Yes its F/LOSS, Open source is the game and under the GNU General Public License v3

I have added the license in the repo.

Feel free to modify and keep the rooting system alive in your own way.

[monsiu]

Feel free to drop any other query for clarrification.

[IzzySoft]

Cool, thanks! And here's one more: there are multiple tags/releases already, but they all identify as

package: name='com.example.android' versionCode='1001' versionName='1.0.0'

while the tags state v0.1 resp. v0.2. Could you please fix this up by setting the version correctly? E.g. for v0.2 this should have been version: 0.2+2, your next release will probably be version: 0.3+3. The part before the "+" is a string for humans to read, the part following the "+" is an integer for Android to tell versions apart and must always be increased with each new release (how much is up to you). Now if you wonder why above string has versionCode='1001' – that's what flutter does with per-ABI builds. That string comes from your armeabi build, where Flutter says versionCode = versionCode +1000; the arm64 APK will have +2000 and so on.

That done, this fine Custom-RR can enter my Custom-R – oops, sorry: my 3rd-party F-Droid repo for some promo, easier discoverability, and update notifications in the F-Droid clients of those using my repo.

[monsiu]

Wow thanks for the detailed info and instructions.

As i plan on fixing other issues with the app that have been brought up, I will update in due time as per your instructions so you could upload to your third party F droid repo.

Your repo has great stuff too what is its traffic metrics?

[IzzySoft]

Glad I was able to shed some light :smiley: And looking forward to include Custom-RR to my repo then. As for traffic metrics: I keep no stats, I can just rawly look at what Webalizer got from the web logs. And that is just a round-about, as the repo is accessed by two websites (it's integrated with my app listings as well). So monthly transfer volume is around 2 TB with 3..8 Mio visits and close to 200 Mio files transferred.

[monsiu]

thats not bad! dont know what Mio is but i know 2TB is alot haha. btw i have 2 query so the 1st query: I am changing the version number to 0.3+1 as you said but i noticed that i can only do 0.0.3+3 so i believe thats the way its supposed to be done in the pubsec.yaml right? I am not quite sure.

2nd Query i can not seem to find the versionCode='1001' you mentioned in my code. Where can i get it? after compiling or?

I have also commited changes i have made so feel free to reference the code now. Apologies if some of these questions are supposed to be common sense am still new to this :)

[IzzySoft]

dont know what Mio

Million, i.e. 1.000.000 :smile:

i can only do 0.0.3+3

Even better. And don't forget to especially always increase the number following the + when making a new release. Then ideally name the tag v0.0.3 (or c3, depending on which part you want to match) and updates should work easily. As you already use v0.2 now, it will probably be v0.0.3 then. Or 0.3.0+3 and v0.3.0, so your versions do not decrease with the next release :wink:

i can not seem to find the versionCode='1001' you mentioned in my code. Where can i get it?

As I wrote in my comment above: You use Dart/Flutter. So compiling a "fat APK" will take the versionCode as-is from your pubspec.yaml. But when you build per-ABI, Flutter will add for each ABI with a factor for it. Usually that's +1000 for amreabi, +2000 for arm64, and so on (no idea where the order is defined, I'm no Android or Flutter dev). So you will not find that number in your code, but in the resulting APKs (you can check with aapt d badging <apkfile>).

And no apologies needed, all is fine! I see the license, so that part is clear.

Last question from my end: Which ABI do you prefer me to take, armeabi or arm64? armeabi is compatible with more devices (especially older ones, but also newer 64bit devices with the exception of Google's latest Pixel 7 pro), while arm64 is better optimized for newer devices (but would not run on 32bit devices at all). I'll take the armeabi for now; if you want me to switch to arm64, just let me know.

Argh, wait: That's very bad. You use a "demo ID": com.example.android is a very bad choice for a package name / applicationId). I don't mean the fact that Google wouldn't accept any app named com.example.* for their Play Store, but com.example.app is definitely just for testing (and something some friends next door could choose as well, and we'd have a conflict). Better choose a real unique applicationId. Let me check: you have an own domain (monsiutechsolutions.com), perfect. So I'd suggest com.monsiutechsolutions.custom.rr or com.monsiutechsolutions.custom_rr. What do you think?

[monsiu]

i changed the com.example.android, its not in the code anymore so im using com.monsiutechsolutions.custom_rr. Check to confirm :)

im also fixing the issues and am also adding a devices section to help users get everything they need for their device. So i would advice waiting a bit as i implement that. Its not anything fancy but I think it would help.

Ok got it! i'll use 0.0.3+3 and the next would be 0.0.4+4?

Once ready you can take the armeabi, I honestly dont believe in switching to arm64 cause most devices (if not all) that get flashed custom roms and devices are usually old 32bit devices and the good thing about armeabi is it can also support 64bit.

So once the app is in your F-Droid Repo it would be getting updates from here?

[IzzySoft]

i changed the com.example.android, its not in the code anymore so im using com.monsiutechsolutions.custom_rr. Check to confirm :)

I'm not a dev, so the code is a bit hard for me to "confirm". Once there's an APK I can check – if you want me to do that before tagging a new release, you can just attach it here maybe.

im also fixing the issues and am also adding a devices section to help users get everything they need for their device. So i would advice waiting a bit as i implement that. Its not anything fancy but I think it would help.

Good points, so attaching an (intermediate) APK (not for publishing) here gets an even stronger point.

Ok got it! i'll use 0.0.3+3 and the next would be 0.0.4+4?

That's fine – especially as with renaming the package, the relation to "0.2" wouldn't matter as it's effectively a new app. But before finally deciding on 0.0.3 versus 0.3.0, may I point you to Semantic Versioning for its meaning? A 0.0.x would also be conceived as a "very early alpha" by users.

Let me give a short version of semver: <major>.<minor>.<patch>, where "patch" means minor changes/fixes/updates to the "minor" – and "major" marks a, say, "final stable release of this tree", like a "huge milestone being reached" (my humble interpretation, please read details behind the link). Which is why I'd suggest going with 0.3.0 instead of 0.0.3. But of course that's up to you: as pointed out I'm no Android dev, so I cannot tell about your code in that depth. And not even having tried the app, I cannot tell from a user's perspective either :see_no_evil:

Once ready you can take the armeabi,

I fully agree, including your reasoning. I have some arm64 devices here I flash as well, but for the flashing process that should not matter :wink:

So once the app is in your F-Droid Repo it would be getting updates from here?

Exactly. My updater checker runs daily and looks for new releases. If it found any with a matching APK attached, it will pull and process that (malware scan, library scan and all that) and finally add it to the repo.