versionCode not increased?

[IzzySoft]

Please remember to always increase versionCode when making a new release. Android uses that internally to tell versions apart; so if it was not increased, Android will think that new APK was already installed and not offer it for update.

That said, my scanner just reported

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

This 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.

One more point: the APK at release 1.1 contains a keystore file (assets/debug23.keystore) which should not be there, it's not part of the repo here (if I build the APK from here I cannot find that file inside). Please keep that file from being included with future releases, thanks!

[AbdurazaaqMohammed]

Please remember to always increase versionCode when making a new release. Android uses that internally to tell versions apart; so if it was not increased, Android will think that new APK was already installed and not offer it for update.

Thanks I will do this in future

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.

Thanks, I did not know about this, I will add it in future

One more point: the APK at release 1.1 contains a keystore file (assets/debug23.keystore) which should not be there, it's not part of the repo here (if I build the APK from here I cannot find that file inside). Please keep that file from being included with future releases, thanks!One more point: the APK at release 1.1 contains a keystore file (assets/debug23.keystore) which should not be there, it's not part of the repo here (if I build the APK from here I cannot find that file inside). Please keep that file from being included with future releases, thanks!

It's just debug key for signing APK after AntiSplit/merge so it can be installed, I think it was missing because of Android gitignore template including .keystore files, I uploaded it now

[IzzySoft]

Thanks!

It's just debug key for signing APK after AntiSplit/merge so it can be installed, I think it was missing because of Android gitignore template including .keystore files, I uploaded it now

So it was intended to be included, and is needed for the app to work properly? As you describe it, the process will make automated updates impossible as the signature will no longer match. You're aware of that? Android checks the signature when installing an app. If the APK is an update to an existing app, it will be rejected if the signature does not match (security measure so malicious folks cannot simply replace apps on your phone). That means, when your "merged APK" is installed, updates are only possible the very same way: extracting them from another device using APKExtactor, and install the resulting APK. I didn't find a hint to that in the app or in the description here.

Btw: that app names are not displayed in the current beta you know, right?

And I guess a trashbin icon next to the floppy one is planned, as the app requests the permission to delete packages?

[IzzySoft]

PS: you seem to build your APK outside the git tree, but have versionInfo enabled. Could you please build future releases from a clean tree at the commit the release tag points to? Makes it easier to detect where it was built from. For some background on this:

At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). Trying for yours, we were able to successfully generate the APK using ./gradlew assembleRelease, but the resulting APKs were not identical – as ours was containing the proper commit hash in its version info, but yours was not. We've now removed the .git directory (rm -rf .git) after pulling the latest commit (which provides the keystore file discussed above), and succeeded with a reproducible build. That's not the ideal way (though it works), so we hope for your help there.

        build:
          - git checkout d0b1cf811c01a57ba0bae471f24a109135915c49
          - rm -rf .git
          - chmod +x gradlew
          - ./gradlew assembleRelease

(the explicit checkout makes auto-update of the RB impossible – but that was a one-timer we can consider solved now. The rm -rf .git is not exactly a show-stopper, but sub-optimal: the versionInfo in the resulting APK often helps detecting which commit the APK was really built from, should RB fail, and sometimes then allows fixing them).

We'd appreciate if you could help keeping your build reproducible. We've prepared some hints on reproducible builds for that.

---

PPS: You might have wondered about some references – apologies, I totally forgot to mention: I was just adding your app to the IzzyOnDroid repo, it will show up here with the next sync around 6 pm UTC, and will already carry the green shield of a reproducible build, congrats!

[AbdurazaaqMohammed]

So it was intended to be included, and is needed for the app to work properly? As you describe it, the process will make automated updates impossible as the signature will no longer match. You're aware of that? Android checks the signature when installing an app. If the APK is an update to an existing app, it will be rejected if the signature does not match (security measure so malicious folks cannot simply replace apps on your phone).

Yes I know, in order to merge split APK (If not clear, signing option only applies to merging split APKs to regular APK. Not extracting apps installed as regular APK or extracting split APK as an archive) resources.arsc must be merged and the original signature will not be valid. The main use of merging split APK is to perform further modification on it in which case it would have to be signed anyway, the option to sign is mostly just to install and test if it worked. I will add information about this in the app.

Btw: that app names are not displayed in the current beta you know, right?

I forgot to set the text color because it was visible on my device. I should not have upload this release at all.

And I guess a trashbin icon next to the floppy one is planned, as the app requests the permission to delete packages?

Upon pressing an app it should open menu like Lucky Patcher with this and more options

We'd appreciate if you could help keeping your build reproducible. We've prepared some hints on reproducible builds for that.

Thanks, I will try to follow these from now on

PPS: You might have wondered about some references – apologies, I totally forgot to mention: I was just adding your app to the IzzyOnDroid repo

Thanks a lot, but please don't upload version that not working, I just uploaded new release hopefully fixing these issues

[IzzySoft]

The main use of merging split APK is to perform further modification

Ah! Yeah, that's clear then, thanks!

I forgot to set the text color because it was visible on my device.

Oopsie :see_no_evil: Want me to open a PR, sending you the metadata set up at IzzyOnDroid so you can maintain it (and e.g. replace screenshots, update description etc)? Using fastlane structures for that, be welcome to the IzzyOnDroid Fastlane Documentation for guidance.

(RB): Thanks!

Thanks a lot, but please don't upload version that not working,

I tested it before (cursory; had to make the screenshots as there were none in your repo). It was marked beta, so that seemed to match the "status quo". I assumed that your marking it "release" (and not "pre-release") meant it's OK to distribute, apologies if I was to quick with that!

I just uploaded new release hopefully fixing these issues

Update was already picked up – and smoothly made it to RB :smiley:

BTW: When I create screenshots, I usually set the clock (easily done via "demo mode" on ADB) to indicate the version the screenshots were taken from. In the current screenshots, the clock shows 01:10, so it was v1.1 :wink: