Add to FDroid or IzzyOnDroid
Hi
Is it possible to add the app to one of the FDroid repos so we can install and update it from there?
Thanks
You can use obtainium for easy access. Otherwise it depends on the repo owner, Izzy is known for hunting down apps like this, so just wait
@IzzySoft can probably add it to his if he wants (I think I've seen it there, but either it was removed for some reason or I've confused it with PI)
Ping was lost it seems – so someone pinged me to look here :rofl:
OK, scanner complains a little here:
Offending libs:
---------------
* Bugsnag exception reporter for Android (/com/bugsnag): Tracking
1 offenders.
Permissions:
------------
* android.permission.REQUEST_INSTALL_PACKAGES
* android.permission.QUERY_ALL_PACKAGES
* android.permission.INTERNET
* dev.zwander.installwithoptions.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION
* android.permission.ACCESS_NETWORK_STATE
* moe.shizuku.manager.permission.API_V23
SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)
@zacharee is bugsnag strictly opt-in – or is anything of it enabled by default? Permissions are clear of course (will add the sensitive ones to the app's "green list" right away). As for DEPENDENCY_INFO_BLOCK, that can easily be avoided with a minor addition to your build.gradle:
android {
dependenciesInfo {
// Disables dependency metadata when building APKs.
includeInApk = false
// Disables dependency metadata when building Android App Bundles.
includeInBundle = false
}
}
For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.
Wondering which way you added the screenshots to the readme as I cannot download them (see that rather frequent for a while, some host called private-userimages.githubcontent.com), nasty stuff. What about Fastlane? PR wanted for that?
Btw: I've tried to build the app from the latest release tag (using ./gradlew assembleRelease) but failed:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:compileReleaseKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction
> Compilation error. See log for more details
Any hints? Would love to establish Reproducible Builds for your app :smiley:
Apart from that, it should become available at IzzyOnDroid with the next sync around 6 pm UTC.
I use a lot of hidden APIs so it won't compile with the default SDK JARs. I can work on replacing the uses with reflection, but it's going to take a while.
Thanks! Please give me a ping when you think it's worth giving it another try with OpenJDK. I can run 17 or 21 here without any issues, in case it's relevant.
The app should compile with a stock Android SDK now, although I haven't tested for crashes coming from reflection mistakes.
Bugsnag crash reporting and performance are enabled by default and can't be disabled in-app, but they shouldn't be collecting anything besides the basics like device model and Android version.
If you go to the README source, the screenshot links aren't from the private domain. GitHub replaces them in the rendered Markdown for some reason.
The app should compile with a stock Android SDK now
Thanks! Trying it now.
Bugsnag crash reporting and performance are enabled by default and can't be disabled in-app
That means we'll have to add the Tracking anti-feature (with the proper explanation). No matter what it reports: it sends data to a remote server without the explicit and informed consent of the person using the app, and that's not needed for the functionality of the app – so strictly speaking, it even violates GDPR, sorry. Statistics ("on which devices is my app used?") are interesting and even helpful ("what devices I should focus my tests on?"), so no complaints – but it must happen with informed consent.
AntiFeatures:
Tracking:
en-US: The app uses Bugsnag which sends reports automatically and cannot be disabled.
de: Die App verwendet Bugsnag, welches automatisch Reports versendet und nicht deaktiviert werden kann.
Can (and will) be removed once you made Bugsnag opt-in. And of course in the case you should remove it entirely.
If you go to the README source, the screenshot links aren't from the private domain. GitHub replaces them in the rendered Markdown for some reason.
Oh? :eyes: github.com/user-attachments/assets/*, indeed! Cool, thanks – and those can be downloaded. That was a very valuable hint to me! :hugs:
The app should compile with a stock Android SDK now
It does, and results in a Reproducible Build – wonderful! So with the next sync around 6 pm UTC, your app will carry the green shield, congrats!
Bugsnag crash reporting and performance are enabled by default and can't be disabled in-app
There is one single option in the Settings and is disabled by default (IDK how effective it is tho): Enable Crash Reports Allow Install With Options to send anonymous crash and error logs to Bugsnag. Disabling this requires an app restart to take effect.
I prefer the Bugsnag to be removed entirely tho (I can't do it myself) and I wonder how much it will save from/reduce the .APK's file size... Or perhaps two versions can be build (and provided as assets in /releases): One with Bugsnag and one without ?
I will appreciate if the changes are also mentioned in /releases, not only in the changelogs file.
Would probably be nice and make sense if the screenshots are displayed as smaller and maybe even in columns, like here for example (but not necessarly): https://github.com/AbdurazaaqMohammed/AntiSplit-M, because they seem to me as unnecessarily large, maybe setting the height to 400, instead of the width will be better, or placing them under details (expandable) will be even better, so they won't load everytime I visit this repo (that's every other day). Also instead of linking the images as attachments, perhaps it will be better if they are uploaded in a visible/accessible folder in the repo and linked/loaded from there, but that will probably have to be done anyway if/when fastlane is handled.
Oh, I guess I do have a toggle, and it's disabled by default. I completely forgot I had that in this app.
Bugsnag does take up about 4.5MB of the 14.7MB total, which is a pretty big chunk, but I don't really have the energy to build and maintain two variants. What I can do is exclude the native components of Bugsnag since this is a purely JVM app.
I saw the commit, can you pls. build and replace the .apk file asset in /releases or I should wait for the next ver. release to see the change ? Thanks in advance.
Zacharee, which E-Mail you use and check more often - the GMail one linked in your profile (which needs updating btw - check Bifrost, which is renamed to SamloaderKotlin) or the one in your site ?
https://apt.izzysoft.de/fdroid/index/apk/dev.zwander.installwithoptions <- You can now link it to the ReadMe if you want ;).
can you pls. build and replace the .apk file asset in /releases
Never replace what's already distributed (except for emergency/security reasons). That APK would never reach those already having installed the previous, nor would it reach IoD. Better make a new release (and in those emergency cases, simply remove the APK from the other release).
You can now link it to the ReadMe if you want
You can even pick a badge for that :wink:
As for size: I do not know what details you need from Bugsnag – but if you're looking for an alternative, here are some listed…
@IzzySoft
The app uses Bugsnag which sends reports automatically and cannot be disabled.
^ I'm not sure that this is correct, given that not only it's optional, but it's also disabled by default as I mentioned previously and the dev. confirmed.
I'm a bit confused on what is active here and what not. So @zacharee can you confirm that by default NOTHING is sent? From Bugsnag's self-description:
library that automatically detects crashes in apps, collects diagnostic information and immediately notifies the development team.
That sounds to me that as soon as it's included, it will do exactly that. Not sure if a toggle can really keep it from doing so. Just having a toggle doesn't mean it does toggle anything (except maybe the graphic). No offense meant of course.
Having a build flavor coming without that would of course not only solve the tracking issue, but also bring the size down :stuck_out_tongue_winking_eye:
You have to call Bugsnag.start() in your code for Bugsnag to actually do anything. I don't call that unless the crash reports toggle is enabled.
Thanks for clarification! Added Bugsnag to the app's "green list" now and removed the anti-feature – effective with the next sync (sorry, missed today's one by 45min).