Attach APK to releases

[IzzySoft]

First, congrats to your first release! And thanks for providing the APK to end-users for easy access! :green_heart: :star_struck:

To not bloat your repo unnecessarily (each new version would mean a growth of ~25M), I'd suggest you attach the APK to releases/ instead (when you edit a release, Github lets you add attachments). That way the APK remains available for everyone – and potential contributors have "less to clone" :wink:

Another weird idea: I'm no Android developer, but I've heard proguard can be used to eliminate unused stuff from the build. This feature might help you reducing the size of the resulting APK, so it might be worth a try.

All the best for your project!

[monolidth]

Thanks for your input. This makes totally sense. I will remove the apk binary.

Regards, William

[monolidth]

Resolved here.

[IzzySoft]

Great, thanks! That was fast :smiley:

Will you also look into Proguard? From other projects I've seen that 20% reduction in size seems absolute realistical. And what's not there can neither cause bugs nor have security issues :smile:

[monolidth]

Yeah, I will take a lot at it. Thanks for your suggestion.

[monolidth]

Update, I tried proguard and the build failed like at: https://github.com/flutter/flutter/issues/28979 However, flutter integrates proguard by default according to the docs, which means that it is not necessary anymore. Regards

[IzzySoft]

OK, thanks – as I wrote, I'm not an Android dev so I didn't know that. Thanks for trying anyway! I'm still confused why some frameworks produce such APK sizes… (no answer required, just thinking aloud :smile:)

[monolidth]

I read a interesting atricle about the flutter apk size.

As you might noticed, the app is written using the flutter framework. The main reason why flutter applications are so huge is because of:

[..] flutter ships a core engine, framework, ICU data, LICENSE file etc with its build output which are mandatory for a flutter app to run.

Thats why native application are much smaller than flutter applications but flutter is still awesome.

[monolidth]

The first is build uses proguard explicity and is 0.1MB larger than without.

[IzzySoft]

Thanks – I thought as much. As wide-spread as it is, one should think someone (eh, the Flutter team) had thought about putting that core in its own APK, making it available to all apps building on top. So one had to install it only once – and not 25 times with each of the apps…

Side-note: when Android 5 dropped support for the GPS notification (i.e. before that you could see whether it was still looking for satellites or already had achieved a fix), a dev was going to put this functionality into a simple app. Seeing that "simple app" got beyond 1.5M in size, he dropped all frameworks and built it "pure". I'm still using this nice little app, it's well below 50k in size…

Some frameworks are really cool. But they come at a price not everyone is willing to pay.

Oh well, I didn't want to complain – but my fingers started typing faster than… :man_shrugging:

[IzzySoft]

"You are building a fat APK…" Oh yeah, so my rant crossed your build :rofl: Yeah, if splits are available, I usually pick the "smallest common denominator" (ARMv7, covers 95% of all devices including arm64). Oh, and here it is, if you don't mind… and I'd also have a badge for you if you wish to link there.

(btw: nice mixed locale, with "Arbeitsverzeichnis on master". We call that DEnglish :rofl:)

[monolidth]

Nice, is it possible to change the following: Author Name: Monolidth Package name: org.receipt_manager

I noticed that the screenshots does not load in the FDROID client and the main app logo and is it also possible to add the sha1 checksum or how does the app validation work?

After, I will add the badge to the repository.

[IzzySoft]

Nice, is it possible to change the following:
Author Name: Monolidth

Updated.

Package name: org.receipt_manager

Nope. Your app identifies as org.receipt_scanner, that value is taken directly from your app. And please don't change that or updates will fail (changing the package name makes it a different app essentially, as that's what it is defined by) – also, it's fine as it is and rather a "cosmetical question". If you insist, that means some work on both ends, yours and mine: you'd need to update your app, and I need to rework its listing in my repo.

I noticed that the screenshots does not load in the FDROID client

Huh? That's strange. The F-Droid client is known for having issues with loading screenshots, but for me those only happened with the F-Droid.org repo (usually when it responds to slow because of high load). Nothing I can do about that, sorry.

is it also possible to add the sha1 checksum or how does the app validation work?

APK signing? Hard to fake a signature unless you have the private key.

After, I will add the badge to the repository.

Great, looking forward to that!

[monolidth]

Nope. Your app identifies as org.receipt_scanner, that value is taken directly from your app. And please don't change that or updates will fail (changing the package name makes it a different app essentially, as that's what it is defined by) – also, it's fine as it is and rather a "cosmetical question". If you insist, that means some work on both ends, yours and mine: you'd need to update your app, and I need to rework its listing in my repo.

My fault. I will not rename the package.

Huh? That's strange. The F-Droid client is known for having issues with loading screenshots, but for me those only happened with the F-Droid.org repo (usually when it responds to slow because of high load). Nothing I can do about that, sorry.

Ah good to know.

APK signing? Hard to fake a signature unless you have the private key. At the moment the apk is not signed. Is there any validation method?

After, I will add the badge to the repository. I did

[monolidth]

See 13e62b17f4964b848aa4fd38b3958f9828463711

[IzzySoft]

I will not rename the package.

Good, thanks!

At the moment the apk is not signed.

Not true. Were it not signed, my server had not accepted it.

Is there any validation method?

$ apksigner verify --verbose repo/org.receipt_scanner_1.apk |grep -v WARN
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Number of signers: 1

$ jarsigner -certs -verify -verbose repo/org.receipt_scanner_1.apk |grep -v WARN

sm      3816 Fri Nov 30 00:00:00 CET 1979 AndroidManifest.xml

      >>> Signer
      X.509, C=US, O=Android, CN=Android Debug
      [certificate is valid from 10/21/20 8:10 PM to 10/14/50 8:10 PM]
      [Invalid certificate chain: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

…

Ugh. You indeed shouldn't sign with a debug key. And remember that changing the key requires the user to uninstall and reinstall the app (the update would not be accepted unless signed with both keys, which AFAIK neither v1 nor v2 support) – so changing to a "real key" should happen as soon as possible (before too many users have installed the app).

See 13e62b1

Cool, thanks!

[monolidth]

I will prior this issue. Thanks.

[monolidth]

It took a while since the android studio beta version is not able to sign application correctly, if you use the flutter framework.

After I updated gradle and I had to rollback since this broke the SDK manager tools.

Now, if the app gets build, the apk gets signed.

Reference: 668197fc1afae51e8957cc0d29def449a0c1e7ab

I would be happy, if you can upload the apk.

[IzzySoft]

That looks like a proper signing key now. I see you changed the package name and hope you'll stick to this one now; I've renamed everything accordingly here and replaced the APK. Will take effect with the next sync in about 18 hours from now.

[monolidth]

Great, yeah I want to stick with the name. That's why I renamed the hole project. Thanks for your effort. I do appreciate this.

[IzzySoft]

Do you want the metadata (summary, description) in Fastlane format? I could sent it as PR (or simply attach here as tarball/Zip if you prefer). Then you could maintain it yourself, and my updater would check it with each release and pick up changes (same goes for F-Droid.org should you head there; you can even use Fastlane for deployment to Play Store, though that most likely will need the Fastlane binaries).

[monolidth]

Yeah, that would be great!

Can you send me a pull request please.

Sorry for the delay. I don't get any notifications in this issue.

[IzzySoft]

Done. In case you wonder: for full_description.txt I've used "simplified Markdown" (i.e. paragraphs and lists delimited by single blank lines) with some minor inline HTML. To my knowledge, this is the best compromise as it's understood by F-Droid (who do simple nl2br and some sanitizing on it), Play Store (similarly), and my repo (converting from Mardown to HTML with some sanitizing). So once established in your repo, I'd adjust my config to check fastlane whenever a new release is pulled.