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:

[drogga]

Maybe https://android.izzysoft.de/repo/apk/io.github.abdurazaaqmohammed.ApkExtractor or https://apt.izzysoft.de/fdroid/index/apk/io.github.abdurazaaqmohammed.ApkExtractor can be linked in the ReadMe and if this is resolved can be closed ?

Dev. - Please use non-generic filenames for the .apk assets in /releases as you do in some of your other repos. TiA. The same for your repo CopyText .apk

[IzzySoft]

@drogga what's wrong with generic file names?

[drogga]

@AbdurazaaqMohammed knows, I've explained it in details a long time ago to him and he agreed, but basically: A mess in the DL folder when keeping .apk files named with the generic app-release.apk, not only when keeping the previous vers. of this one, but also when DLing other APKs from other repos, the browser / DL manager will attach a suffix as (1), (2), (*) before the file extension (some can just replace it) and unless you rename it manually during or after downloading it, it makes a mess to in the folder that's stored. Anyway, it's a low effort task, so it's not something complicated to discuss it much here, can be made automatic and I even offer my help doing it manually, but I don't have permissions (can be easily changed if the owner wants).

[IzzySoft]

Ah, I almost forgot "manual downloads". The downloader here automatically renames the APKs to <packageName>_<versionCode>.apk, whatever they might have been named before :see_no_evil:

[AbdurazaaqMohammed]

Maybe https://android.izzysoft.de/repo/apk/io.github.abdurazaaqmohammed.ApkExtractor or https://apt.izzysoft.de/fdroid/index/apk/io.github.abdurazaaqmohammed.ApkExtractor can be linked in the ReadMe

Added

Please use non-generic filenames for the .apk assets in /releases

Done

[IzzySoft]

Maybe android.izzysoft.de/repo/apk/io.github.abdurazaaqmohammed.ApkExtractor or apt.izzysoft.de/fdroid/index/apk/io.github.abdurazaaqmohammed.ApkExtractor can be linked in the ReadMe

Please use the latter, it gives much more details. The other is just a limited viewer integrated with the app listings there.

While here: description does not speak about removing apps, so I wonder what android.permission.REQUEST_DELETE_PACKAGES is requested for?

[AbdurazaaqMohammed]

Under features:

Basic management (Launch, Uninstall, System app info)

[drogga]

ReadMe - DL buttons images - the GH one has "v" before the version, the IoD one doesn't and I wonder - should/can the page that generates them (shields.io) address this to make them consistent or... ?

[IzzySoft]

@AbdurazaaqMohammed thanks, added to the "green list" with explanation.

As for the "leading v": the IoD APK is taken from releases here, so versionName should be identical. In the APK, there's no such leading v, nor is in the tag name at releases – so maybe drop it from the Github badge for consistency?

[drogga]

Izzy, it's the same in other repos, like for example InstallWithOptions, but I prefer if the "v" is there for both, as it visually explains the meaning of the numbers and it would be even better if it's lowercase "v" with a dot after, indicating that it's short for "version", like "v.1.2.1", anyway, I don't know how this can be addressed, so I will wait for the potential commit to find out ;)

[IzzySoft]

Btw: you should NEVER rename the APKs on existing tags, which have already been distributed – especially not with RB being set up. You'll just have broken verification now for those, because if one tries to reproduce our recipes (originally created and processed with the original file name), they will fail as the APK can no longer be found. This also has lead to auto-updates in the builder being broken, so I'll have to disable that for now in my builder: as you changed the name for the already processed 1.2.1, I cannot change the pattern looked for as that would mean changing the already processed one, which would render the results invalid/not-matching. Thus the update checker will fail on each run (not finding a matching APK) and throw errors, which makes checking harder.

Any ETA when 1.2.2 is due, so we can clean up the mess?

As for the leading v: that's up to the developers of the app. The API at IzzyOnDroid (as well as many other places) will simply return the versionName from the APK – and that's what should be shown on the badges (which is also how shields.io works).

[AbdurazaaqMohammed]

I don't have any idea for new features and I am busy right now. Can i just rename it to app-release.apk (what it was before) again?

[IzzySoft]

Should work, yes. Then feel free to adjust the naming to the wishes of @drogga with the next release. That will mean a one-time error at the RB builder(s), which is easy to fix then though (especially as we aware of it now). Thanks!