Screenshots & Metadata

[IzzySoft]

First thanks for making your app available using a FOSS license :star_struck: Am I assuming correctly this is a module for Xposed? And would you have some screenshots available? Looking to include your app with the IzzyOnDroid repo – and as the "first impression" is important, it'd better start with some good visuals :wink:

Btw, our scanners reported:

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

This can easily be avoided with a minor adjustment 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.

Thanks in advance!

[Nep-Timeline]

Thank you for your advice Since I didn't write the UI for this Xposed module, there are no screenshots available for this module

[IzzySoft]

Thanks for the quick fix! As for screenshots: is there no GUI? Where/how does one select which apps to freeze, or when? I've just translated your Readme using DeepL.com (by myself I could not even read it :see_no_evil:):

Cirno is an app freezer that runs on Android 12+ platforms, it is used to make background apps completely free of CPU resources to improve the overall smoothness of the device.

Cirno is currently only supported on cgroup v2 devices, which means your Linux kernel version needs to be greater than or equal to 5.0.

So I most likely miss some details. Thanks for helping me to understand!

[Nep-Timeline]

no need to select, the module will freeze application automatically

[IzzySoft]

All of them? So one cannot exclude an app needed to run? (Just asking to understand – not to complain :wink:)

[Nep-Timeline]

All of them? So one cannot exclude an app needed to run? (Just asking to understand – not to complain 😉)

by modifying the cfg file, you can specify that the application does not freeze

[IzzySoft]

Thanks! Integrated Cirno with IoD then:

It will show up here with the next sync around 6 pm UTC. Be welcome to pick a badge then to link there e.g. from your Readme here :smiley:

Btw: At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). Trying for yours, I was able to successfully generate the APK using ./gradlew assembleRelease, but the resulting APKs were not identical. Was that APK really built from a clean tree at the commit the tag points to? If so, did I miss some build options? And if not, which commit was it? Here's the differences between your APK and the one I built from the commit the tag points to:

  -rw-r--r--  0.0 unx       56 b-       52 defN 1981-01-01 01:01:02 b89973a3 META-INF/com/android/build/gradle/app-metadata.properties
- -rw-r--r--  0.0 unx       46 b-       48 defN 1981-01-01 01:01:02 b8ff6554 META-INF/version-control-info.textproto
+ -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 5939abba META-INF/version-control-info.textproto
  -rw-r--r--  0.0 unx      885 b-      885 stor 1981-01-01 01:01:02 f9eaa45b assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      167 b-      167 stor 1981-01-01 01:01:02 0846b225 assets/dexopt/baseline.profm
  -rw-r--r--  0.0 unx   963976 b-   963976 stor 1981-01-01 01:01:02 deca088b classes.dex
- -rw-r--r--  0.0 unx     4048 b-     4048 stor 1981-01-01 01:01:02 a9e31f8f lib/arm64-v8a/libcirno.so
- -rw-r--r--  0.0 unx     2804 b-     2804 stor 1981-01-01 01:01:02 bd9a64e4 lib/armeabi-v7a/libcirno.so
- -rw-r--r--  0.0 unx     3112 b-     3112 stor 1981-01-01 01:01:02 b842e6da lib/x86/libcirno.so
- -rw-r--r--  0.0 unx     4048 b-     4048 stor 1981-01-01 01:01:02 28dc6eaa lib/x86_64/libcirno.so
+ -rw-r--r--  0.0 unx     3856 b-     3856 stor 1981-01-01 01:01:02 3aba276b lib/arm64-v8a/libcirno.so
+ -rw-r--r--  0.0 unx     2620 b-     2620 stor 1981-01-01 01:01:02 15a38008 lib/armeabi-v7a/libcirno.so
+ -rw-r--r--  0.0 unx     2924 b-     2924 stor 1981-01-01 01:01:02 e2c71428 lib/x86/libcirno.so
+ -rw-r--r--  0.0 unx     3856 b-     3856 stor 1981-01-01 01:01:02 529f8265 lib/x86_64/libcirno.so
  -rw-r--r--  0.0 unx     3656 b-     3647 defN 1981-01-01 01:01:02 b0438654 assets/main.jar

Taking a look at your META-INF/version-control-info.textproto, that APK was not built from inside the Git repo at all:

generate_error_reason: NO_SUPPORTED_VCS_FOUND

In comparison to that, here's the one from our build:

repositories {
  system: GIT
  local_root_path: "$PROJECT_DIR"
  revision: "a26ad205cdfbb37b0145b71e0af68fa293d5d90b"
}

(where "revision" is the git commit your tag points to).

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!

cc @obfusk

[obfusk]

Taking a look at your META-INF/version-control-info.textproto, that APK was not built from inside the Git repo at all:

We can either just rm -fr the .git/ directory in the recipe on our end in these cases. Or upstream can set android.buildTypes.release.vcsInfo.include = false.

The .so files (apart from having different ELF build-IDs) seem to be built using an llvm-based obfuscator instead of the regular Android ndk. Why build a FOSS app with an obfuscator? Especially since the .cpp file doesn't contain any code.

[Nep-Timeline]

Thanks! Integrated Cirno with IoD then:

It will show up here with the next sync around 6 pm UTC. Be welcome to pick a badge then to link there e.g. from your Readme here 😃

Btw: At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). Trying for yours, I was able to successfully generate the APK using ./gradlew assembleRelease, but the resulting APKs were not identical. Was that APK really built from a clean tree at the commit the tag points to? If so, did I miss some build options? And if not, which commit was it? Here's the differences between your APK and the one I built from the commit the tag points to:

  -rw-r--r--  0.0 unx       56 b-       52 defN 1981-01-01 01:01:02 b89973a3 META-INF/com/android/build/gradle/app-metadata.properties
- -rw-r--r--  0.0 unx       46 b-       48 defN 1981-01-01 01:01:02 b8ff6554 META-INF/version-control-info.textproto
+ -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 5939abba META-INF/version-control-info.textproto
  -rw-r--r--  0.0 unx      885 b-      885 stor 1981-01-01 01:01:02 f9eaa45b assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      167 b-      167 stor 1981-01-01 01:01:02 0846b225 assets/dexopt/baseline.profm
  -rw-r--r--  0.0 unx   963976 b-   963976 stor 1981-01-01 01:01:02 deca088b classes.dex
- -rw-r--r--  0.0 unx     4048 b-     4048 stor 1981-01-01 01:01:02 a9e31f8f lib/arm64-v8a/libcirno.so
- -rw-r--r--  0.0 unx     2804 b-     2804 stor 1981-01-01 01:01:02 bd9a64e4 lib/armeabi-v7a/libcirno.so
- -rw-r--r--  0.0 unx     3112 b-     3112 stor 1981-01-01 01:01:02 b842e6da lib/x86/libcirno.so
- -rw-r--r--  0.0 unx     4048 b-     4048 stor 1981-01-01 01:01:02 28dc6eaa lib/x86_64/libcirno.so
+ -rw-r--r--  0.0 unx     3856 b-     3856 stor 1981-01-01 01:01:02 3aba276b lib/arm64-v8a/libcirno.so
+ -rw-r--r--  0.0 unx     2620 b-     2620 stor 1981-01-01 01:01:02 15a38008 lib/armeabi-v7a/libcirno.so
+ -rw-r--r--  0.0 unx     2924 b-     2924 stor 1981-01-01 01:01:02 e2c71428 lib/x86/libcirno.so
+ -rw-r--r--  0.0 unx     3856 b-     3856 stor 1981-01-01 01:01:02 529f8265 lib/x86_64/libcirno.so
  -rw-r--r--  0.0 unx     3656 b-     3647 defN 1981-01-01 01:01:02 b0438654 assets/main.jar

Taking a look at your META-INF/version-control-info.textproto, that APK was not built from inside the Git repo at all:

generate_error_reason: NO_SUPPORTED_VCS_FOUND

In comparison to that, here's the one from our build:

repositories {
  system: GIT
  local_root_path: "$PROJECT_DIR"
  revision: "a26ad205cdfbb37b0145b71e0af68fa293d5d90b"
}

(where "revision" is the git commit your tag points to).

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!

cc @obfusk

Because the version in release I signed

[Nep-Timeline]

also, the so file is empty because I'm not currently planning to write JNI code but later, I might use JNI

[Nep-Timeline]

Taking a look at your META-INF/version-control-info.textproto, that APK was not built from inside the Git repo at all:

We can either just rm -fr the .git/ directory in the recipe on our end in these cases. Or upstream can set android.buildTypes.release.vcsInfo.include = false.

The .so files (apart from having different ELF build-IDs) seem to be built using an llvm-based obfuscator instead of the regular Android ndk. Why build a FOSS app with an obfuscator? Especially since the .cpp file doesn't contain any code.

The reason is simple, because another of my projects needs to be protected with oLLVM. But by looking at CMakeList.txt file, you can see that I didn't enable any obf, I just compiled with the same Android NDK as that project

[Nep-Timeline]

The release version was compiled on my own computer, not by GitHub actions

[IzzySoft]

Because the version in release I signed

Nope, signing has nothing to do with that diff. That is taken care for (or we would not have a single RB app instead of the hundreds alone in the IzzyOnDroid repo).

because another of my projects needs to be protected with oLLVM.

Then why do you apply it to THIS project, and not just to the other? And what kind of "protection" are you talking about? As Fay correctly pointed out, this app here is open source. So if the source is open (and everyone can see), what is the use of obfuscating the compiled code?

The release version was compiled on my own computer, not by GitHub actions

My APK was compiled on one of my computers, and also not by Github actions. Your version must have been compiled "outside the git tree", i.e. with no .git directory present – while I compiled directly from the cloned repo, as it's usually done.

[Nep-Timeline]

Because the version in release I signed

Nope, signing has nothing to do with that diff. That is taken care for (or we would not have a single RB app instead of the hundreds alone in the IzzyOnDroid repo).

because another of my projects needs to be protected with oLLVM.

Then why do you apply it to THIS project, and not just to the other? And what kind of "protection" are you talking about? As Fay correctly pointed out, this app here is open source. So if the source is open (and everyone can see), what is the use of obfuscating the compiled code?

The release version was compiled on my own computer, not by GitHub actions

My APK was compiled on one of my computers, and also not by Github actions. Your version must have been compiled "outside the git tree", i.e. with no .git directory present – while I compiled directly from the cloned repo, as it's usually done.

I am not sure about the reasons for the differences in question 1 The explanation for question 2 is that all of my projects use the same Android NDK oLLVM is applied to the Android NDK, so no matter what project I compile, as long as I use the Android NDK, it is compiled based on oLLVM

[Nep-Timeline]

Question 3:

[Nep-Timeline]

Moreover, even though I use oLLVM as a compiler, I have not obfuscate my code in any way

[IzzySoft]

I am not sure about the reasons for the differences in question 1

Partly explained by your screenshot: I see no .git directory there (maybe you can outline your release workflow, starting with the moment of making the "final commit", so we can find out what to "fix/improve" there?). Which explains the difference for META-INF/version-control-info.textproto. We could include a step here to remove that directory before starting the build if needed, as mentioned by Fay – though that would only be my second choice. This version info is often helpful to find out what commit an APK was really built from, if RB fails.

As for the .so files: if it's not obfuscation, the difference might be caused by different NDK versions (as for oLLVM, I need to wait for @obfusk to answer that). Which one are you using?

[Nep-Timeline]

I will resolve the oLLVM issue in the next version (Using NDK 26)

[obfusk]

As for the .so files: if it's not obfuscation, the difference might be caused by different NDK versions (as for oLLVM, I need to wait for @obfusk to answer that). Which one are you using?

I don't know about other differences since there is no actual code in the .so (yet), but as the .so has an embedded version string (and ELF build-ID), using oLLVM for one of the builds only will never be reproducible (and I don't think using it in the rebuilder makes any sense).

I will resolve the oLLVM issue in the next version

Does that mean not using it any more?

[IzzySoft]

So it's either no oLLVM here – or no RB?

[Nep-Timeline]

As for the .so files: if it's not obfuscation, the difference might be caused by different NDK versions (as for oLLVM, I need to wait for @obfusk to answer that). Which one are you using?

I don't know about other differences since there is no actual code in the .so (yet), but as the .so has an embedded version string (and ELF build-ID), using oLLVM for one of the builds only will never be reproducible (and I don't think using it in the rebuilder makes any sense).

I will resolve the oLLVM issue in the next version

Does that mean not using it any more?

yes, ndk26 do not use ollvm

[IzzySoft]

Thanks! Please give us a ping when it's ready and we can check again.

[IzzySoft]

Looks like you forgot the ping, there are a few new releases I see. But, where do you build the APKs? The embedded versionInfo says: generate_error_reason: NO_SUPPORTED_VCS_FOUND. Which means you didn't build from within the repo, but from some export/tarball. Which alone already breaks RB.

So basically, the structure still looks the very same:

  -rw-r--r--  0.0 unx       56 b-       52 defN 1981-01-01 01:01:02 b89973a3 META-INF/com/android/build/gradle/app-metadata.properties
- -rw-r--r--  0.0 unx       46 b-       48 defN 1981-01-01 01:01:02 b8ff6554 META-INF/version-control-info.textproto
+ -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 4bfbf4c7 META-INF/version-control-info.textproto
  -rw-r--r--  0.0 unx      886 b-      886 stor 1981-01-01 01:01:02 fa74d265 assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      167 b-      167 stor 1981-01-01 01:01:02 0846b225 assets/dexopt/baseline.profm
  -rw-r--r--  0.0 unx   964440 b-   964440 stor 1981-01-01 01:01:02 d2c53f11 classes.dex
- -rw-r--r--  0.0 unx     3936 b-     3936 stor 1981-01-01 01:01:02 e8971c7f lib/arm64-v8a/libcirno.so
- -rw-r--r--  0.0 unx     2724 b-     2724 stor 1981-01-01 01:01:02 f0290ff8 lib/armeabi-v7a/libcirno.so
- -rw-r--r--  0.0 unx     3060 b-     3060 stor 1981-01-01 01:01:02 5072333c lib/x86/libcirno.so
- -rw-r--r--  0.0 unx     3984 b-     3984 stor 1981-01-01 01:01:02 eba7c820 lib/x86_64/libcirno.so
+ -rw-r--r--  0.0 unx     3784 b-     3784 stor 1981-01-01 01:01:02 5fb9760f lib/arm64-v8a/libcirno.so
+ -rw-r--r--  0.0 unx     2564 b-     2564 stor 1981-01-01 01:01:02 448d806d lib/armeabi-v7a/libcirno.so
+ -rw-r--r--  0.0 unx     2900 b-     2900 stor 1981-01-01 01:01:02 a29ca9da lib/x86/libcirno.so
+ -rw-r--r--  0.0 unx     3832 b-     3832 stor 1981-01-01 01:01:02 6c9595fc lib/x86_64/libcirno.so
  -rw-r--r--  0.0 unx     3656 b-     3647 defN 1981-01-01 01:01:02 b0438654 assets/main.jar

I will resolve the oLLVM issue in the next version

That would have been the previous release then. I guess something happened and you did not yet get to it? No offense meant, just asking for clarification.

[Nep-Timeline]

Looks like you forgot the ping, there are a few new releases I see. But, where do you build the APKs? The embedded versionInfo says: . Which means you didn't build from within the repo, but from some export/tarball. Which alone already breaks RB.generate_error_reason: NO_SUPPORTED_VCS_FOUND

So basically, the structure still looks the very same:

  -rw-r--r--  0.0 unx       56 b-       52 defN 1981-01-01 01:01:02 b89973a3 META-INF/com/android/build/gradle/app-metadata.properties
- -rw-r--r--  0.0 unx       46 b-       48 defN 1981-01-01 01:01:02 b8ff6554 META-INF/version-control-info.textproto
+ -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 4bfbf4c7 META-INF/version-control-info.textproto
  -rw-r--r--  0.0 unx      886 b-      886 stor 1981-01-01 01:01:02 fa74d265 assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      167 b-      167 stor 1981-01-01 01:01:02 0846b225 assets/dexopt/baseline.profm
  -rw-r--r--  0.0 unx   964440 b-   964440 stor 1981-01-01 01:01:02 d2c53f11 classes.dex
- -rw-r--r--  0.0 unx     3936 b-     3936 stor 1981-01-01 01:01:02 e8971c7f lib/arm64-v8a/libcirno.so
- -rw-r--r--  0.0 unx     2724 b-     2724 stor 1981-01-01 01:01:02 f0290ff8 lib/armeabi-v7a/libcirno.so
- -rw-r--r--  0.0 unx     3060 b-     3060 stor 1981-01-01 01:01:02 5072333c lib/x86/libcirno.so
- -rw-r--r--  0.0 unx     3984 b-     3984 stor 1981-01-01 01:01:02 eba7c820 lib/x86_64/libcirno.so
+ -rw-r--r--  0.0 unx     3784 b-     3784 stor 1981-01-01 01:01:02 5fb9760f lib/arm64-v8a/libcirno.so
+ -rw-r--r--  0.0 unx     2564 b-     2564 stor 1981-01-01 01:01:02 448d806d lib/armeabi-v7a/libcirno.so
+ -rw-r--r--  0.0 unx     2900 b-     2900 stor 1981-01-01 01:01:02 a29ca9da lib/x86/libcirno.so
+ -rw-r--r--  0.0 unx     3832 b-     3832 stor 1981-01-01 01:01:02 6c9595fc lib/x86_64/libcirno.so
  -rw-r--r--  0.0 unx     3656 b-     3647 defN 1981-01-01 01:01:02 b0438654 assets/main.jar

I will resolve the oLLVM issue in the next version

That would have been the previous release then. I guess something happened and you did not yet get to it? No offense meant, just asking for clarification.

Yeah, I didn't build it using the source code in the repo, but my own source code

[IzzySoft]

Why? You don't want RB?

[Nep-Timeline]

Why? You don't want RB?

because I'm lazy, I didn't upload github at first.

[IzzySoft]

Don't you use git for a local clone? The current workflow really makes RB harder to achieve (and keep up)…

PS: developing inside a git repo tree brings other advantages as well. Like the following:

git pull  # get the latest code from your Github
# edit foobar.java, make a big mistake and mess it up totally. Now easily get the previous version back:
git checkout foobar.java

You also can save "interim versions" by simply using git add then, and when having messed up something reset to the latest one you added – without having committed even. And many other things, eg. using git diff to review what you changed…

[Nep-Timeline]

Don't you use git for a local clone? The current workflow really makes RB harder to achieve (and keep up)…

PS: developing inside a git repo tree brings other advantages as well. Like the following:

git pull  # get the latest code from your Github
# edit foobar.java, make a big mistake and mess it up totally. Now easily get the previous version back:
git checkout foobar.java

You also can save "interim versions" by simply using git add then, and when having messed up something reset to the latest one you added – without having committed even. And many other things, eg. using git diff to review what you changed…

Yes, I don't use it

[IzzySoft]

Ah. I'd strongly recommend giving it a try, for sooo many reasons :wink:

[Steake]

Bro, would it really be that hard to put together UI for this application? Because editing the CFG file every time you want to select an app for freezing or not is kind of impractical.

Thinking about doing myself.

but the app isn't even a RB

[IzzySoft]

@Steake I cannot help with the UI, sorry. (if you wonder why I respond to that: I suspect apart from you I'm the only one here in this issue who "bro" could apply to :stuck_out_tongue_winking_eye:)

[Nep-Timeline]

Bro, would it really be that hard to put together UI for this application? Because editing the CFG file every time you want to select an app for freezing or not is kind of impractical.

Thinking about doing myself.

but the app isn't even a RB

Freezer has a UI, Cirno doesn't Anyway, it's open source, you can write your own UI and submit the PR :)