make APKs available outside PlayStore

[IzzySoft]

Did/Would you consider making the APKs available outside PlayStore (e.g. by attaching them to their corresponding releases)? Not everyone has access to that walled garden. Thanks in advance!

[ibnux]

i never upload it to playstore, its only available in this Github Releases

upload to F-Droid still got error

[IzzySoft]

You cannot "upload" to F-Droid. You can request inclusion. If accepted, they'd build and distribute.

Thanks for making the APK available at releases! I've just checked it for possible inclusion with my repo. No "offending libraries" (e.g. Tracking or proprietary libs) found, which is good! But:

Dangerous flags:
----------------
* usesCleartextTraffic
* debuggable

Dangerous Filters:
------------------
android.accessibilityservice.AccessibilityService

Could you outline what those are needed for? debuggable definitely should not be there for an APK intended for distribution. The other two might have their needs and then are most likely fine – if those needs are made transparent :wink:

Next, the signing key:

Number of signers: 1
Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: 34fc986d566899f48677ac4c038179fafae25ff820b57e3dc734e42b05523d3b
Signer #1 certificate SHA-1 digest: 04833227f600edc0a15b2a2afd90d240f85116fe
Signer #1 certificate MD5 digest: 74b754e45a2ae148b3390cb378458403
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

That's a debug key, also not intended for APKs to be distributed. Could you please create (and use) a proper release key for that? For reference and some background, please see https://gitlab.com/IzzyOnDroid/repo/-/issues/477

Thanks a lot!

[ibnux]

Dangerous flags:

• usesCleartextTraffic

Not All Users can create MQTT Server with HTTPS

• debuggable

This is Because Github Action Release, i will try to use my signing, because runner run on my server

But you can use this release, it from my signing key
https://github.com/ibnux/Android-SMS-Gateway-MQTT/releases/tag/v2024.4.20

Dangerous Filters:

android.accessibilityservice.AccessibilityService

this is for reading USSD Request, and is not to dangerous, because user need to activate it manually if they need USSD command, some phone need to use AccessibilityServices, others not

[ibnux]

i try to submit to F-Droid, still not understand 😁

https://gitlab.com/fdroid/rfp/-/issues/2725

[IzzySoft]

Thanks for your explanations! Yes, that makes sense. The APK also looks fine, with a single thing for a future release maybe:

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

which can easily be avoided:

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.

I could use that APK now, but then could not enable updates: there are 2 newer releases with the same tag name syntax but the debug signed APKs attached, so the updater would immediately try to fetch the latest. Could be worked around two ways: either marking those with the "wrong APK" attached as pre-releases (which my updater would ignore then unless explicitly told not to), or using different tag naming patterns for those (e.g. pre-2024.4.21 instead of v2024.4.21, so I could nail the updater to the tag name. But then, there's another issue:

package: name='com.ibnux.smsgatewaymqtt' versionCode='1' versionName='1.0'

Do all the APKs use the very same versionCode? That would make updates hard, as there'd be no update notifications (Android uses versionCode to tell versions apart – so it would always think "already installed" and not offer the newer APK for update – which is why versionCode must be increased with each release). And versionName is not updated either (nor matching the tag names)? Then the updater variant with different tag naming patterns wouldn't work either (and those using the app could never tell wich version is installed, as versionName is what is shown to them for this purpose).

i try to submit to F-Droid, still not understand

That's F-Droid.org's repo, they'd build your app from its sources themselves. And what their bot points out there is:

• Fastlane is missing: I can provide you that once your app is set up with my repo, as for that purpose I'd create those structures. I could then send them up here via PR, and you'd be welcome to my Fastlane Cheat Sheet to build upon that
• ObjectBox is not FOSS AFAIK, so it's a show-stopper for F-Droid
• that Maven repo is not listed as one of the trusted maven repos and thus another show-stopper

[ibnux]

@IzzySoft i have change version to v1.2
version code always change if i don't forget it :D

i create separate branch for ObjectBox, so new version not use ObjectBox Again

[IzzySoft]

Thanks! So now v1.2.1 also has "1.2+2" (both versions not changed again) :stuck_out_tongue_winking_eye: It also still carries the debug flag and still is signed using a debug key, so I cannot (yet) add it to my repo. Glad to see the dependency blob gone, though :smiley:

i create separate branch for ObjectBox, so new version not use ObjectBox Again

Great! That will make it eligible for F-Droid then, hopefully (if that Maven repo is dealt with as well). If you want to establish reproducible builds there, you'll have to deal with the debug flag & key as well, though.