Issues with the APKs at your releases

[IzzySoft]

The APKs at your releases have some minor issues. Is there a specific reason while they are compiled for debug (android:debuggable is set to true)? Further, they don't show the correct versioning. The APK from 1.1 e.g. identifies as

package: name='com.android.example.camera2.basic' versionCode='1' versionName='1.0.0'

which marks it as first release ever (versionCode='1') which it definitely is not, and versionName is not the expected '1.1' as the release suggests. Those values would need to be set here right before making the release build. Without versionCode being increased, Android would not see the new APK as update for the already installed app.

Last question: What license is this app covered by? In the code I see plenty of references to Apache-2.0, does that apply to the entire app?

Thanks in advance!

[Ilya-Muromets]

Thanks for the comments, I'm very much not an app developer so the answer to most questions is "woops, my bad".

Will fix the version number / debuggable on my next version. Regarding license, however, I think all the references to Apache-2.0 are from the camera2basic app I built this from. In general I release my work under the MIT license.

Do you have resources/advice for what I would do in this case? I assume I need to add a blurb somewhere saying "this is based off the camera2basic app which has xyz license" and remove the other references to Apache-2.0?

[IzzySoft]

I'm very much not an app developer so the answer to most questions is "woops, my bad".

Hehe, happens. I'm no Android dev at all, just learned some pieces as side-effects.

Will fix the version number / debuggable on my next version.

Wonderful! Please give me a ping when that's there, so I can check again!

Do you have resources/advice for what I would do in this case?

To my knowledge, MIT and Apache-2.0 are compatible (but I'm no lawyer). You could declare the app MIT and point out that pieces are covered by Apache-2.0, outlining the projects that refers to. The relevant parts should be in section 4 of the Apache-2.0 license, especially:

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

The other points of that section are covered as you kept the license headers in each file. That should be fine IMHO – but as pointed out, IANAL. There are also some libraries providing license dialogs which would make it easy for you to show the relevant parts inside your app.

[Ilya-Muromets]

Finally found the time to add some fixes to the app, added updated/corrected license headers so now it should look a lot clearer (Basically my MIT with a copy of the original Apache 2.0). Thanks for pointing out the debuggable:true by the way! I did not realize that even when building for release I was for some reason still setting debuggable to be true, and the app was losing a lot of performance because of it.

[IzzySoft]

Thanks! And yes: versioning looks good, and the MIT license shows up fine in your repo :smiley: Now you'd just need to sign it using a release key:

package: name='com.android.example.camera2.basic' versionCode='3' versionName='1.2' platformBuildVersionName='13' platformBuildVersionCode='33' compileSdkVersion='33' compileSdkVersionCodename='13'
Verifies
Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Number of signers: 1
Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: b750f080fc73a6bf7164206581b123d32fef3d6c592d3f0b8a3b8b7ff9a4a3e8
Signer #1 certificate SHA-1 digest: 3bfd93e5ed81d913bdfc647c2ef1ea69ddf9fe29
Signer #1 certificate MD5 digest: 7885266af7c78048c3fbb823ff2a5f97
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

See:

• Why debug certificate is not safe to sign android APKs?
• issues when using local debug keystore

And please take care for this one:

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

which is easy to solve:

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.

[Ilya-Muromets]

I overwrote the 1.2 release due to some issues I had with the commit (was tracking the wrong files). Let me know if this resolves the dependency/signing problems?

[IzzySoft]

Clean like after a fresh shower :partying_face:

$ iod shell scanapk Pani.apk

Libraries detected:
-------------------
* Android Support v4 (/android/support/v4): Development Framework, Apache-2.0
* AndroidX Activity (/androidx/activity): Utility, Apache-2.0
* Android Jetpack Annotations (/androidx/annotation): Utility, Apache-2.0
* Arch (/androidx/arch): Utility, Apache-2.0
* AppCompat (/androidx/appcompat): Utility, Apache-2.0
* Cardview (/androidx/cardview): UI Component, Apache-2.0
* Android Support Library collections (/androidx/collection): Utility, Apache-2.0
* Constraint Layout Library (/androidx/constraintlayout): Utility, Apache-2.0
* Coordinatorlayout (/androidx/coordinatorlayout): UI Component, Apache-2.0
* Androidx Core (/androidx/core): Utility, Apache-2.0
* AndroidX Cursor Adapter (/androidx/cursoradapter): Utility, Apache-2.0
* Android Support Library Custom View (/androidx/customview): UI Component, Apache-2.0
* Documentfile (/androidx/documentfile): UI Component, Apache-2.0
* Drawerlayout (/androidx/drawerlayout): UI Component, Apache-2.0
* Dynamicanimation (/androidx/dynamicanimation): UI Component, Apache-2.0
* Exifinterface (/androidx/exifinterface): Utility, Apache-2.0
* AndroidX Fragment (/androidx/fragment): UI Component, Apache-2.0
* Interpolator (/androidx/interpolator): UI Component, Apache-2.0
* androidx.legacy (/androidx/legacy): Utility, Apache-2.0
* Lifecycle (/androidx/lifecycle): Utility, Apache-2.0
* Loader (/androidx/loader): Utility, Apache-2.0
* AndroidX Local Broadcast Manager (/androidx/localbroadcastmanager): Utility, Apache-2.0
* Navigation (/androidx/navigation): Utility, Apache-2.0
* Print (/androidx/print): Utility, Apache-2.0
* Recyclerview (/androidx/recyclerview): Utility, Apache-2.0
* Android Activity Saved State (/androidx/savedstate): Utility, Apache-2.0
* Transition (/androidx/transition): UI Component, Apache-2.0
* Vectordrawable (/androidx/vectordrawable): UI Component, Apache-2.0
* Android Jetpack VersionedParcelable (/androidx/versionedparcelable): Utility, Apache-2.0
* Viewpager (/androidx/viewpager): UI Component, Apache-2.0
* AndroidX Widget ViewPager2 (/androidx/viewpager2): UI Component, Apache-2.0
* Glide (/com/bumptech/glide): Utility, BSD-2-Clause
* Google Material Design (/com/google/android/material): Utility, Apache-2.0
* Kotlin (/kotlin): Utility, Apache-2.0
* kotlinx.coroutines (/kotlinx/coroutines): Utility, Apache-2.0
* IntelliJ IDEA (/org/intellij): Utility, Apache-2.0

No offending libs found.

Permissions:
------------
* android.permission.CAMERA

So expect the following to show up here with the next sync around 7 pm UTC:

New releases should be pulled within 24h of your making them and have an APK attached there. And be welcome to pick a badge if you want to link there e.g. from your Readme :smiley:

[Ilya-Muromets]

Great, thank you so much!

[IzzySoft]

You're welcome! If you want the metadata I've set up in my repo (Fastlane structures, see my Fastlane Cheat Sheet on how to work with that) to get control over the presentation of your app there, let me know and I send it over with a PR.

[Ilya-Muromets]

Looks good to me, just added the link!

[IzzySoft]

What happened to your signing key, @Ilya-Muromets? Your current release was rejected by the updater here:

2024-10-18 19:45:42,817 WARNING: "com.android.example.camera2.basic_4.apk" is signed by a key that is not allowed:
6a7e54a86bee7b3a9840bbca7964acda18ffd470dc615a24ec538397f890e929

I've had to temporarily disable updates now until this is clarified. I hope you still have access to the previous signing key? For details, please see How to keep your key safe and what measures to take for the event of loss?

[Ilya-Muromets]

Oh sorry, I recently migrated computers (and wiped my HD) and didn't realize my keystore wasn't backed up anywhere.

I made a new keystore (which I have now backed up) so should hopefully not happen again.

[IzzySoft]

Ah, so we're having that issue again now (unfortunately, this happens more often than I'd like). So how can we prove now it's really you? Should someone have hacked your Github account, they'd come exactly with this kind of reasoning (no offense meant).

• you don't have access to your previous key anymore, so we cannot use that as proof
• you did not sign your commits with your own GPG/PGP key, so no proof there either
• no separate path of contact was established (e.g. an email address, or an account at the Fediverse), nor do we have a person who could vouch for you

Signing is a security feature. It's intended to confirm a.o. updates really came from the intended person/group. If the key changes, that breaks…

OK, thanks for the OTR verification! Going to initialize the switch then. You've already taken care for a backup of the keystore this time, so it hopefully won't happen again. May I suggest looking into "signed commits" as well? :wink:

Wait… what? Did you change the packageName as well now? From com.android.example.camera2.basic to com.android.example.camera? If you really need to change the packageName, maybe use a proper domain as well while on it? com.example is intended for testing, not for distribution – Google e.g. wouldn't accept that into Playstore. As the key has changed, this indeed is the best time to fix that as well.

[Ilya-Muromets]

Weird, not sure what happened with packageName, I thought I had updated it to com.android.pan (?) But I was refactoring the whole code (going from two modules to one) and in the process had to also update Android Studio and probably broke something, will look into that!

[Ilya-Muromets]

I'll take down v1.3 for now and try to fix this tmrw

[IzzySoft]

Thanks! And AFAIK, com.android is rather the domain used by AOSP (and partly by Google with things they "took over" into their proprietary domain). Why not using your own domain, ilyac.info, for that? like e.g. info.ilyac.pan?

[Ilya-Muromets]

Does this look correct? (sorry github doesn't let me attach .apk files directly) Pani.apk.zip

[IzzySoft]

Does this look correct?

On a quick look (aapt d badging): looks perfect, thanks!

github doesn't let me attach .apk files directly

Indeed not. But remember Github is run by Microsoft, so it just looks at the file extension to decide whether it's allowed. So you can simply rename an APK to *.zip to attach it – no need to put it inside another ZIP :wink: Added charm of this approach: we can check for reproducibility with just referencing the link, without manually downloading and unzipping the file.

That said: just give me a ping once the new release is available. I'll then initiate the switch:

• adding the new app as a, well, new app
• disabling updates on the "old app"
• adding a note to the "old app's" description that it was rebranded, linking to the new one

That way those who had the "old one" installed and wonder about missing updates have a chance to find it. After about a month overlap, the "old one" will be removed from IzzyOnDroid, and only the "new one" will be continued.

Hope that sounds fine with you?

[Ilya-Muromets]

Actually, I think there might be a chance I can recover my old keystore. I'm pretty sure I copied my android studio folder to one of our basement computers at some point, let me see if I can recover it first!

[IzzySoft]

Sure, good idea! Though only those who look thoroughly would notice, as changing the applicationId/packageName means it's an entirely new app anyway :wink:

[Ilya-Muromets]

No dice anyways, unfortunately. Found the computer but no keystore.

Just posted the release with the .apk above, thanks!

[IzzySoft]

OK, then let me prepare everything. Meanwhile, a note for the next release by what our scanners report:

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

easily solved with a minor addition to your build.gradle: oops, no need to post the details again I see, just scroll up to the end of this comment :see_no_evil:

OK, new app has been established, and "old one" git a note pointing to it – both effective with the next sync around 6 pm UTC. Timer for self-destruct of the "old app" set to 2024-11-23.

[Ilya-Muromets]

I swear I fixed that one. Will patch for next release, thank