Removing BugSnag and other dependencies and useless code to make it lighter

[drogga]

@jaredkotoff
https://github.com/jaredkotoff/WiFiList

Can you pls. remove the BugSnag and other dependencies and useless code to make it lighter (not just in package size), just like the mod by KirIif' / Kirlif (and maybe do the same for InstallWithOptions, which is also by zacharee) ?

I had to contact you like this, because you don't have the Issues / Discussions tabs enabled in your fork.
BTW, you can ping/mention ErrrorMaxx / errr-maxx-builds to merge your PR in their repo and probably reduce the Sync Fork CI action workflow to couple of days, or minimum 24H, instead of every hour or less, which is too often & unnecessary IMO and maybe try to figure out a way to automatically grab the Changelog/What's New from Play Store in /Releases.

Thank You in advance.

[jaredcat]

@drogga I'm not really interested in making any more modifications besides adding CI.
I also don't want anything to break and have to spend time investigating it.

I would just say make modification on this fork, this way mine is pure and should always be a good upstream for yours.

I don't think ErrrorMaxx is active, so they'll probably never merge it 🤷🏻

[drogga]

@jaredcat
Thanks for the reply, I saw that you've adjusted the schedule a bit, even tho I don't understand this cron thing.

The problem is that I don't know how to do it myself (removing BugSnag), since I'm not a coder, I only know 2 human languages, no Java, Kotlin or any other, just some basic things here and there.

"I don't think ErrrorMaxx is active, so they'll probably never merge it 🤷🏻"
^ I wonder isn't it pointless in that case - why do you even bother creating PRs there, even a new Draft one if you think it's in vain (waste of time), instead of just do changes on your fork only...

[jaredcat]

@drogga I set up my repo to automatically build new versions when it detects the app version has changed.
I also recently discovered obtainium so should have totally automatic updates!

even tho I don't understand this cron thing.

I find this website helpful https://crontab.guru/

I'm not a coder

Never too late to learn. It could be a good way of getting into it by trying to tackle this.
I highly recommend learning at least a little bit of coding. It can be helpful in your daily life!

[drogga]

👍
I don't use Obtanium because I don't update apps, unless something breaks or there are new features I care about (or substantial bug fixes), if something works - I leave it as is.

Cron - Thanks for the site, I've found it myself after I commented that I don't understand it and I now know mere about it, but I still think that this linux or whatever format is super unnecessary to be used in coding, where normal date/time stamps can be used to be in human readable format, instead of numbers that don't make sense.

I agree, I've even contributed to the SkyTube repo, but that's basic, I still can't remove completely the unnecessary BugSnag analytics, I don't even currently have any IDE, that's years ahead from what I can do.

I found that the Actions builds are with obfuscated res (minify) and with ~5 MB less file size, aren't they supposedly to be larger debug builds ?, those usually are in other repos and the release builds aren't obfuscated (which I prefer) and with larger size, anyway it's not worth it given the overall .apk file size to obfuscate/minify the code just to save that little (~5 MB), so whatever you do - pls. don't minify the Release builds as well, but you can remove it for the Actions ones, or even better - get rid of the BugSnag, which will actually save a lot and the .apk will probably be less than 10 MB, you can do it in my (this) repo if you don't want to in your's (if you have time), just say so I will sync the repo to match Zacharee's and you can make a PR with some signing key for a non-obfuscated release build if necessary ;)

BTW, since A.13/14 I'm pretty sure most firmwares can show the pass right in the Wi-Fi networks details (I'm not sure if it's in the AOSP as well or only the most popular brands implemented it), so this app will be kind of pointless in future (especially that it requires Shizuku, which have to be reActivated after reboot, unless your system is rooted), even tho it might be more convenient having a search filter (WiFi or the BT settings don't have such) and listing them all alomg with their passwords in one place, instead of having to do multiple clicks to navigate to various sub-settings and authenticate the screen lock method if you have one to be able to reveal the paas.

[jaredcat]

I don't even currently have any IDE

Android Studio is all you need!

aren't they supposedly to be larger debug builds

Yes the actions build debug versions: https://github.com/jaredcat/WiFiList/actions/workflows/build.yml

The release page has fully signed release builds so they can be updated instead of having to be uninstalled a re-installed each time. But I might add the debug versions to the releases too for those uncomfortable with me signing the release versions.

BugSnag, which will actually save a lot and the .apk will probably be less than 10 MB, you can do it in my (this) repo if you don't want to in your's (if you have time)

I'm definitely not going to do this in my repo. I don't intend to change any of the code of the app itself, and it might break the auto build process. If someone wants to fork from me and do that, though, that would be ideal. I could also create a separate repo for this, but I probably won't. I have a lot of other projects to work on (and I already spent so much time on this just for the fun of it)

Im pretty sure most firmwares can show the pass right in the Wi-Fi networks details (I'm not sure if it's in the AOSP as well or only the most popular brands implemented it),

It can, but it's cumbersome. I still actually prefer this app, like you said, as it's a lot quicker and shows all the networks instead of having to look at them one at a time.

[drogga]

None of the apps debug builds I've opened had obfuscated resources (isMinifyEnabled = false, isShrinkResources = false, no proguard, not that there are the first 2 there at all) and AFAIK they shouldn't, hence they are always larger in size, quite the opposite in your fork repo - that's what I pointed out. Open the 2 APKs (from actions and releases) with 7-Zip for example and compare the content of /res to see what I mean.

[jaredcat]

Ah then idk what that is. Feel free to make a PR to fix it

[drogga]

IDK how to fix it, but you probably either have to touch the actions workflow files or exclusively add and set/declare the 2 (minify & shrink) attributes/flags/params to false in app/build.gradle.kts, but that's a wild guess.