Add Boundo Meta-app: Info & Manager

[cliuff]

Boundo Meta-app (repo link) shows info about apps installed, and organizes them into categories. App info includes API level, split APKs (AAB), adaptive icons, technologies (Kotlin, Compose, Flutter...), native libs, app components, and more.

[offa]

Thanks for your suggestion. As far as I can tell, the project seems to include some proprietary Google services.

[IzzySoft]

Offending libs:
---------------
* Google Mobile Services (/com/google/android/gms): NonFreeComp
* Google Play Core (/com/google/android/play/core): NonFreeNet,NonFreeComp
* Xiaomi Push (/com/xiaomi/mipush): NonFreeComp,NonFreeNet,Tracking

3 offenders.

Yupp, confirmed. No idea why an app that is intended to analyze what's installed on your device, needs push notifications. Or, what neither Readme nor "description" at PlayStore state, which apps it will install (requests the INSTALL_PACKAGES permission) – though it does not have the INTERNET permission as well, so it should not be anything it downloads by itself (so probably local APK files).

[cliuff]

- Google services are used for downloading dynamic app features (which is now considered legacy but stays there). - Xiaomi push SDK is used for analyzing apps that support it, since Meta App does not access internet, this is not really a concern. - And INSTALL_PACKAGES is used for retrieving precise installer info of apps (as stated in docs), the permission is granted to system apps only (uses can manually convert an app to system via some methods like root), and would not be a concern for normal users.

Is it required to remove Google services and Xiaomi Push SDK for Meta App to be accepted?

[offa]

Thanks @IzzySoft!

Is it required to remove Google services and Xiaomi Push SDK for Meta App to be accepted?

Would be nice; at least a FOSS flavour without them would needed.

[IzzySoft]

this is not really a concern.

It is, as we're talking FOSS here – and all 3 mentioned libraries are proprietary.

the permission is granted to system apps only

Correct, to my knowledge – so here we could agree on "not really a concern", as it would require to maually and explicitly convert the app to a system app.

at least a FOSS flavour without them would needed.

AckAck! That way the variant including those proprietary libs can be shipped to "that proprietary walled garden", while the foss variant can be included with IzzyOnDroid/F-Droid.

[cliuff]

Would you check if the new FOSS release meets all requirements?

[IzzySoft]

It does – but it will fail Reproducible Builds (see e.g. Reproducible Builds, special client support and more at IzzyOnDroid for some background) for multiple reasons:

• you're using build timestamps. That makes the build non-deterministic. See No funny build-time-generated IDs for details. This might be possible to get RB adding something like export SOURCE_DATE_EPOCH=1577836800 to the begin of the build process – but the safer approach is to do without that entirely.
• you seem to build via app bundles. Chances to get such a build RB are, if at all, less than 10%.

Would you consider adjusting that?

[cliuff]

Unfortunately I am seeing some inconsistency issues regarding baseline.prof in builds. I will investigate and maybe find a temporary workaround.

[IzzySoft]

Thanks for digging in! I've been told that using BundleTool makes it more difficult to achieve RB. Curious if it's possible at all. Just trying that with another app, which also uses BundleTool to generate the universal APK, not yet reached the goal there either. Please keep me updated, and let me know when we should give it a try. Though we should continue that part in your app's issue tracker I guess; you can simply ping me from there then.

[IzzySoft]

Btw, I tried to build v5.0.2 following the steps from the Github action. Build succeeds, but no APKs were created:

build:
  - git reset --soft f4b5a2115f1b34c7bce1fd1b5d81f8c807a3ee06
  - wget -q https://github.com/google/bundletool/releases/download/1.18.1/bundletool-all-1.18.1.jar -O doconfig/bundletool.jar
  - sha256sum -c <<< '675786493983787ffa11550bdb7c0715679a44e1643f3ff980a529e9c822595c  doconfig/bundletool.jar'
  - sed -r 's/val configSigning =.*/val configSigning = false/' -i app/build.gradle.kts
  - chmod +x gradlew
  - ./gradlew dependencies
  - ./gradlew :app:genFossApks -Pver.inc=true
  - find . -name '*.apk'

(git reset was needed as the APK at the release was not built from the tagged commit, according to the embedded vcsInfo). The find command returned an empty result – i.e. there was no APK found.

[cliuff]

@IzzySoft the output file's extension is .apks rathe than .apk, the apk set contains a single universal.apk file.

[IzzySoft]

🤦‍♂️ My bad. I know the bundle needs to be extracted, but somehow thought the gradle task would take care for that…

OK, I get APKs now, but they are not RB. First, you seem not to build the release APKs with the Github action, but locally on a Windows machine (we see Windows line breaks in META-INF/services/*), but this we can adjust for. Then, there are differences in the DEX files. Those diffs look a bit like originating from a "dirty build" – which is confirmed by the fact that the APK says to have not been built from the tagged commit, but from the previous one – while containing changes only available at the tagged commit. The third thing differing is res/raw/aboutlibraries.json.

I'll attach you the diffs here: diff.zip

Current build recipe for v5.0.2 (run on Debian bookworm with OpenJDK 17, after the code was cloned from the tag):

build:
  - git reset --soft f4b5a2115f1b34c7bce1fd1b5d81f8c807a3ee06
  - wget -q https://github.com/google/bundletool/releases/download/1.18.1/bundletool-all-1.18.1.jar -O doconfig/bundletool.jar
  - sha256sum -c <<< '675786493983787ffa11550bdb7c0715679a44e1643f3ff980a529e9c822595c  doconfig/bundletool.jar'
  - sed -r 's/val configSigning =.*/val configSigning = false/' -i app/build.gradle.kts
  - chmod +x gradlew
  - ./gradlew dependencies
  - ./gradlew :app:genFossApks -Pver.inc=true
  - unzip -l app/build/outputs/app-universal-foss.apks
  - unzip app/build/outputs/app-universal-foss.apks -d app/build/outputs

But maybe we should continue this in your issue tracker, @cliuff? Feel free to open an issue there and ping me from it (and maybe link the two).

[cliuff]

@IzzySoft thanks for the diff, however I am fully aware of the differences in the current release APKs. The point being, the blocking issue now is that the baseline.prof file in the APK cannot be reproduced stablely, as mentioned in a previous comment. And as replied in the corresponding isssue tracker, stability can be achieved by using the official Gradle plugin to generate baseline profiles.

I uploaded foss release apk locally built on my machine out of convenience. RB cannot be achieved until I find time to address the baseline profile issue (other minor diffs can be resolved by choosing the APK built from GitHub action, except aboutlibraries.json which will be looked into). And I will open an issue for this when further plan is available.

[IzzySoft]

Sounds like a good plan, thanks! Looking forward to that then.