IzzyOnDroid inclusion

[shuvashish76]

Hello, I requested for IzzyOnDroid inclusion which is the largest third-party F-Droid repo. As he suggested, please do not use play-services-oss-licenses as it is not free/libre. FOSS alternatives are listed here.

[teixeira0x]

Thanks for making this suggestion, I will remove this library!

[teixeira0x]

released!

[shuvashish76]

Ping @IzzySoft for the request to rescan & report the results.

[shuvashish76]

@teixeira0x android.permission.ACCESS_NETWORK_STATE why this permission necessary ?

Details

 Results from [AppManager](https://github.com/MuntashirAkon/AppManager)

[IzzySoft]

Scan results:

No offending libs found.

Permissions:
------------
* android.permission.WRITE_EXTERNAL_STORAGE
* android.permission.READ_EXTERNAL_STORAGE
* android.permission.READ_MEDIA_VIDEO
* android.permission.ACCESS_NETWORK_STATE
* com.teixeira.subtitles.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION

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

package: name='com.teixeira.subtitles' versionCode='1' versionName='1.1.0' platformBuildVersionName='14' platformBuildVersionCode='34' compileSdkVersion='34' compileSdkVersionCodename='14'

Looks much better now! The two remaining things are no show-stoppers, but should be solved with the next release (please do not replace the APK at the currently latest tag – not a good idea with what already has been distributed). Going bottom-up: you must always increase versionCode with each release as that's what Android uses internally to tell versions apart. Otherwise your updates would reach no existing installations: they'd always say "already here". That would be this line in your build.gradle. Another tiny modification to the very same file would take care for the DEPENDENCY_INFO_BLOCK as well:

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.

I've also went one step further, testing your APK if it is reproducible (see: Reproducible bulds, special client support and more in our repo), but while I was able to successfully generate the APK using ./gradlew assembleRelease, the differences to the one provided at your latest release were huge. Was that APK really built from the commit the tag points to? If so, did I miss some build options? And if not, which commit was it? Here's the diff of the APKs (yours from the tag, and the one I've built from the commit the tag points to):

-------------------------------
--- /dev/fd/63  2024-08-09 01:06:11.648621550 +0200
+++ /dev/fd/62  2024-08-09 01:06:11.648621550 +0200
@@ -146,1214 +146,1212 @@
   32-bit CRC value (hex):                         852a0981
   AndroidManifest.xml
   32-bit CRC value (hex):                         8006b987
-  res/--.xml
-  32-bit CRC value (hex):                         573381d8
-  res/-5.png
-  32-bit CRC value (hex):                         2d80e948
-  res/-9.png
-  32-bit CRC value (hex):                         07b43d5a
-  res/-A.xml
-  32-bit CRC value (hex):                         59e462e3
-  res/-Y.xml
-  32-bit CRC value (hex):                         3194e6af
+  res/-1.xml
+  32-bit CRC value (hex):                         2201be97
+  res/-5.xml
+  32-bit CRC value (hex):                         b7be1b78
+  res/-7.xml
+  32-bit CRC value (hex):                         baaef170
+  res/-8.xml
+  32-bit CRC value (hex):                         0161ec4d
+  res/-A.png
+  32-bit CRC value (hex):                         3c674f9b
+  res/-B.png
+  32-bit CRC value (hex):                         ead36c57
+  res/-B.xml
+  32-bit CRC value (hex):                         5dcbf80d
+  res/-D.xml
+  32-bit CRC value (hex):                         1c333237
+  res/-J.png
+  32-bit CRC value (hex):                         34f21c1e
+  res/-N.png
+  32-bit CRC value (hex):                         5390d72d
+  res/-Q.xml
+  32-bit CRC value (hex):                         91d1cdde
   res/-c.xml
-  32-bit CRC value (hex):                         df4a83b8
-  res/-e.png
-  32-bit CRC value (hex):                         4c4dea4e
-  res/-e.xml
-  32-bit CRC value (hex):                         2807ab07
-  res/-i.png
+  32-bit CRC value (hex):                         e9ee8900
+  res/06.xml
+  32-bit CRC value (hex):                         098446ce
+  res/0C.xml
+  32-bit CRC value (hex):                         701cb167
+  res/0E.xml
+  32-bit CRC value (hex):                         b6ca0c0a
+  res/0G.png
…

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

Looking forward to your reply!

PS: while integrating your app with the IzzyOnDroid repo (where it will show up with the next sync) I've created Fastlane structures with the metadata (app description and graphics). I gladly send them over via a PR if you want them, so you can maintain them here and thus control how your app is presented. The IzzyOnDroid Fastlane Documentation can guide you with that. Just let me know if you want to have it. Here's what to expect:

[IzzySoft]

PS: Be welcome to pick a badge to link to your app at IoD eg from your Readme :smiley:

[teixeira0x]

@teixeira0x android.permission.ACCESS_NETWORK_STATE why this permission necessary ?

Details

This permission is probably from the ExoPlayer library.

[teixeira0x]

Scan results:

No offending libs found.

Permissions:
------------
* android.permission.WRITE_EXTERNAL_STORAGE
* android.permission.READ_EXTERNAL_STORAGE
* android.permission.READ_MEDIA_VIDEO
* android.permission.ACCESS_NETWORK_STATE
* com.teixeira.subtitles.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION

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

package: name='com.teixeira.subtitles' versionCode='1' versionName='1.1.0' platformBuildVersionName='14' platformBuildVersionCode='34' compileSdkVersion='34' compileSdkVersionCodename='14'

Looks much better now! The two remaining things are no show-stoppers, but should be solved with the next release (please do not replace the APK at the currently latest tag – not a good idea with what already has been distributed). Going bottom-up: you must always increase versionCode with each release as that's what Android uses internally to tell versions apart. Otherwise your updates would reach no existing installations: they'd always say "already here". That would be this line in your build.gradle. Another tiny modification to the very same file would take care for the DEPENDENCY_INFO_BLOCK as well:

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.

I've also went one step further, testing your APK if it is reproducible (see: Reproducible bulds, special client support and more in our repo), but while I was able to successfully generate the APK using ./gradlew assembleRelease, the differences to the one provided at your latest release were huge. Was that APK really built from the commit the tag points to? If so, did I miss some build options? And if not, which commit was it? Here's the diff of the APKs (yours from the tag, and the one I've built from the commit the tag points to):

-------------------------------
--- /dev/fd/63  2024-08-09 01:06:11.648621550 +0200
+++ /dev/fd/62  2024-08-09 01:06:11.648621550 +0200
@@ -146,1214 +146,1212 @@
   32-bit CRC value (hex):                         852a0981
   AndroidManifest.xml
   32-bit CRC value (hex):                         8006b987
-  res/--.xml
-  32-bit CRC value (hex):                         573381d8
-  res/-5.png
-  32-bit CRC value (hex):                         2d80e948
-  res/-9.png
-  32-bit CRC value (hex):                         07b43d5a
-  res/-A.xml
-  32-bit CRC value (hex):                         59e462e3
-  res/-Y.xml
-  32-bit CRC value (hex):                         3194e6af
+  res/-1.xml
+  32-bit CRC value (hex):                         2201be97
+  res/-5.xml
+  32-bit CRC value (hex):                         b7be1b78
+  res/-7.xml
+  32-bit CRC value (hex):                         baaef170
+  res/-8.xml
+  32-bit CRC value (hex):                         0161ec4d
+  res/-A.png
+  32-bit CRC value (hex):                         3c674f9b
+  res/-B.png
+  32-bit CRC value (hex):                         ead36c57
+  res/-B.xml
+  32-bit CRC value (hex):                         5dcbf80d
+  res/-D.xml
+  32-bit CRC value (hex):                         1c333237
+  res/-J.png
+  32-bit CRC value (hex):                         34f21c1e
+  res/-N.png
+  32-bit CRC value (hex):                         5390d72d
+  res/-Q.xml
+  32-bit CRC value (hex):                         91d1cdde
   res/-c.xml
-  32-bit CRC value (hex):                         df4a83b8
-  res/-e.png
-  32-bit CRC value (hex):                         4c4dea4e
-  res/-e.xml
-  32-bit CRC value (hex):                         2807ab07
-  res/-i.png
+  32-bit CRC value (hex):                         e9ee8900
+  res/06.xml
+  32-bit CRC value (hex):                         098446ce
+  res/0C.xml
+  32-bit CRC value (hex):                         701cb167
+  res/0E.xml
+  32-bit CRC value (hex):                         b6ca0c0a
+  res/0G.png
…

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

Looking forward to your reply!

PS: while integrating your app with the IzzyOnDroid repo (where it will show up with the next sync) I've created Fastlane structures with the metadata (app description and graphics). I gladly send them over via a PR if you want them, so you can maintain them here and thus control how your app is presented. The IzzyOnDroid Fastlane Documentation can guide you with that. Just let me know if you want to have it. Here's what to expect:

I have released a new version trying to fix these issues.

[shuvashish76]

@teixeira0x android.permission.ACCESS_NETWORK_STATE why this permission necessary ? Details

This permission is probably from the ExoPlayer library.

Similar report from another app https://github.com/yogeshpaliyal/KeyPass/issues/557 If possible please remove the unnecessary permission in next release. ThankYou

[IzzySoft]

This permission is probably from the ExoPlayer library.

You can override that, see e.g. Removing Unwanted Manifest Permissions With tools:node

I have released a new version trying to fix these issues.

Thanks! There are automated update checks in place at IzzyOnDroid, usually set for "daily" (apps no longer maintained or releasing only once a year or less are checked less frequently), so your update should be pulled with the next run around 6 pm UTC.

Retrying for RB now (builder just fired up), let's see… Nope, similar diff to the one above. Would be most likely this hint:

if you're certain you're building from the same commit but still seeing differences in AndroidManifest.xml, res/*.xml, or resources.arsc, it's likely something is different about the build method, options, and/or configuration, which should be addressed before trying to fix other issues.

We have mostly res/*.xml, resources.arsc and res/*.png here. The latter could be caused if you use crunching, do you? As that's non-deterministic. The former: I just run ./gradlew assembleRelease from within the project root using Debian Bookworm, with JDK 17. Do you do anything different? According to your workflow here, the only difference I see is that you use ubuntu:latest, while I use debian:bookworm-slim, which AFAIK should be no issue.

[teixeira0x]

Essa permissão provavelmente vem da biblioteca ExoPlayer .

Você pode substituir isso, veja, por exemplo, Removendo permissões de manifesto indesejadas com ferramentas: nó

Lancei uma nova versão tentando corrigir esses problemas.

Obrigado! Há verificações de atualização automatizadas em vigor no IzzyOnDroid, geralmente definidas para "diárias" (aplicativos que não são mais mantidos ou são lançados apenas uma vez por ano ou menos são verificados com menos frequência), então sua atualização deve ser retirada com a próxima execução por volta das 18h UTC.

Tentando novamente para RB agora (o construtor acabou de ser inicializado), vamos ver... Não, diff similar ao acima. Provavelmente seria esta dica:

se você tem certeza de que está compilando a partir do mesmo commit, mas ainda vê diferenças em AndroidManifest.xml, res/*.xml, ou resources.arsc, é provável que algo esteja diferente no método de compilação, nas opções e/ou na configuração, o que deve ser resolvido antes de tentar corrigir outros problemas.

Temos principalmente res/*.xml, resources.arsce res/*.pngaqui. O último pode ser causado se você usar crunching, não é? Como isso não é determinístico. O primeiro: eu apenas executo ./gradlew assembleReleasede dentro da raiz do projeto usando Debian Bookworm, com JDK 17. Você faz algo diferente? De acordo com seu fluxo de trabalho aqui , a única diferença que vejo é que você usa ubuntu:latest, enquanto eu uso debian:bookworm-slim, o que AFAIK não deve ser problema.

I'll take a look at this, but in the future I'll probably need this permission because I want to allow the user to create their own subtitles without having to download the video, just by pasting a URL.

The difference in compilation may be caused by the fact that I'm compiling using AndroidIDE. I'll try to compile using GitHub's own actions or Terminal in the next release.

[shuvashish76]

in the future I'll probably need this permission because I want to allow the user to create their own subtitles without having to download the video, just by pasting a URL..

Download and edit opensubtitles similar to SubHub ‽ Nice, thanks for the info.😃

[IzzySoft]

The difference in compilation may be caused by the fact that I'm compiling using AndroidIDE. I'll try to compile using GitHub's own actions or Terminal in the next release.

Ah, thanks! Please give me a ping when that APK is available then, so I can try again. And please make sure to stick with the "first basic rule" from hints on reproducible builds, which then rules out a lot of errors to start with :wink:

[teixeira0x]

A diferença na compilação pode ser causada pelo fato de que estou compilando usando o AndroidIDE . Tentarei compilar usando as próprias ações do GitHub ou o Terminal na próxima versão.

Ah, obrigado! Por favor, me avise quando o APK estiver disponível, para que eu possa tentar novamente. E, por favor, certifique-se de seguir a "primeira regra básica" das dicas sobre compilações reproduzíveis , que então descarta muitos erros para começar 😉

okay, thanks

[shuvashish76]

20 PR for fastlane & download badges

[IzzySoft]

Thanks @shuvashish76! Updated the YAML here so Fastlane will get checked and pulled with each future release now.

[teixeira0x]

@IzzySoft Can you check the version I just released?

[IzzySoft]

Check for what? Oh, right, RB. And congrats! It just was confirmed to be reproducible :partying_face: Green shield should show up with the next sync around 6 pm UTC then, when the new release is being pulled in. Meanwhile, here's your welcome toot to make people aware:

Eek, announced the winter time UTC match :see_no_evil: OK, by that time it should definitely be visible :rofl: