search

Oppzippy / OpenSCQ30

Cross platform application for controlling settings of Soundcore headphones. Supports desktop (CLI and GTK4 GUI), Android, and Web (PWA using Web Bluetooth).
https://oppzippy.github.io/OpenSCQ30/
GNU General Public License v3.0
86 stars 3 forks source link

build question #139

Open IzzySoft opened 6 days ago

IzzySoft commented 6 days ago

I've followed the build instructions from the Readme to my best understanding, ending up with this build recipe:

          - git clone https://github.com/rust-lang/rustup.git -b 1.25.1
          - export ANDROID_NDK=/opt/sdk/ndk/${PROVISIONING_NDK}
          - ${BUILD_REPO_DIR}/rustup/rustup-init.sh -y --target armv7-linux-androideabi --target aarch64-linux-android --target i686-linux-android --target x86_64-linux-android
          - source $HOME/.cargo/env
          - cargo install cargo-ndk
          - cd android
          - ./gradlew assembleRelease
          - find . -name '*.apk'

However, the only APKs found are:

+ find . -name '*.apk'
./app/build/outputs/apk/bluetooth/release/app-bluetooth-release-unsigned.apk
./app/build/outputs/apk/demo/release/app-demo-release-unsigned.apk

not the android/app/build/outputs/apk/release/app-release-unsigned.apk the readme mentions. As I didn't want a demo, I took the other one – but that's a 64 MB APK instead of the expected 7.5 MB one your releases indicate.

Can you please let me know what I might have done wrong there? Thanks in advance!

Oppzippy commented 6 days ago

app-bluetooth-release-unsigned.apk is the correct one, my mistake. ./gradlew assembleRelease by default should strip debug symbols from binaries, but that's probably not happening if the apk is 64MB. Are there any warnings about that failing?

Oppzippy commented 6 days ago

One other mistake I had in the build instructions: ./gradlew assembleBluetoothRelease should be used instead of ./gradlew assembleRelease to skip building the demo variant.

IzzySoft commented 6 days ago

Yes, I remember some "unable to strip" – but must admit I paid them not too much attention as I see them quite often (background: https://codeberg.org/IzzyOnDroid/rbtlog – as you can see, there are already hundreds of apps covered, and yours would be the second Rust one).

Thanks for confirming I've picked the correct APK, and also for mentioning the flavor to include to skip the demo one. I could run the build again and provide you the full log if it helps. I've also kept the APK, so I can peek into it to compare sizes. Here're the .so from mine:

   10096  Stored    10096   0% 1981-01-01 01:01 9734baa0  lib/arm64-v8a/libandroidx.graphics.path.so
  168176  Stored   168176   0% 1981-01-01 01:01 ed136417  lib/arm64-v8a/libjnidispatch.so
17923656  Stored 17923656   0% 1981-01-01 01:01 2c7e8484  lib/arm64-v8a/libopenscq30_android.so
    7252  Stored     7252   0% 1981-01-01 01:01 9a714d3a  lib/armeabi-v7a/libandroidx.graphics.path.so
  122296  Stored   122296   0% 1981-01-01 01:01 ed1882f4  lib/armeabi-v7a/libjnidispatch.so
14623436  Stored 14623436   0% 1981-01-01 01:01 7f7cea05  lib/armeabi-v7a/libopenscq30_android.so
  122784  Stored   122784   0% 1981-01-01 01:01 4298d12a  lib/armeabi/libjnidispatch.so
  150924  Stored   150924   0% 1981-01-01 01:01 2d572a0c  lib/mips/libjnidispatch.so
  141904  Stored   141904   0% 1981-01-01 01:01 1a68d4c4  lib/mips64/libjnidispatch.so
    9284  Stored     9284   0% 1981-01-01 01:01 3d9afc66  lib/x86/libandroidx.graphics.path.so
  120184  Stored   120184   0% 1981-01-01 01:01 c30eacff  lib/x86/libjnidispatch.so
14415700  Stored 14415700   0% 1981-01-01 01:01 3eea4567  lib/x86/libopenscq30_android.so
   10760  Stored    10760   0% 1981-01-01 01:01 81bd88ae  lib/x86_64/libandroidx.graphics.path.so
  118584  Stored   118584   0% 1981-01-01 01:01 b6b1460b  lib/x86_64/libjnidispatch.so
17335808  Stored 17335808   0% 1981-01-01 01:01 373b90d7  lib/x86_64/libopenscq30_android.so

as compared to yours:

   10096  Stored    10096   0% 1981-01-01 01:01 9734baa0  lib/arm64-v8a/libandroidx.graphics.path.so
  157720  Stored   157720   0% 1981-01-01 01:01 7c30fd53  lib/arm64-v8a/libjnidispatch.so
 1175000  Stored  1175000   0% 1981-01-01 01:01 557494a7  lib/arm64-v8a/libopenscq30_android.so
    7252  Stored     7252   0% 1981-01-01 01:01 9a714d3a  lib/armeabi-v7a/libandroidx.graphics.path.so
  112188  Stored   112188   0% 1981-01-01 01:01 8f2cdb72  lib/armeabi-v7a/libjnidispatch.so
  872652  Stored   872652   0% 1981-01-01 01:01 34a67c71  lib/armeabi-v7a/libopenscq30_android.so
  122784  Stored   122784   0% 1981-01-01 01:01 4298d12a  lib/armeabi/libjnidispatch.so
  150924  Stored   150924   0% 1981-01-01 01:01 2d572a0c  lib/mips/libjnidispatch.so
  141904  Stored   141904   0% 1981-01-01 01:01 1a68d4c4  lib/mips64/libjnidispatch.so
    9284  Stored     9284   0% 1981-01-01 01:01 3d9afc66  lib/x86/libandroidx.graphics.path.so
  112108  Stored   112108   0% 1981-01-01 01:01 76982304  lib/x86/libjnidispatch.so
 1211192  Stored  1211192   0% 1981-01-01 01:01 9522fa41  lib/x86/libopenscq30_android.so
   10760  Stored    10760   0% 1981-01-01 01:01 81bd88ae  lib/x86_64/libandroidx.graphics.path.so
  108632  Stored   108632   0% 1981-01-01 01:01 e4a572de  lib/x86_64/libjnidispatch.so
 1235640  Stored  1235640   0% 1981-01-01 01:01 e90c5cc8  lib/x86_64/libopenscq30_android.so

So yes, it's them (especially libopenscq30_android.so).

In case it matters: build was running on Debian bookworm with OpenJDK 17 and NDK 27.2.12479018 (which I've picked from your build.gradle).

Oppzippy commented 5 days ago

By any chance, are you building the latest tag (ndk version 26.3.11579264) but using the ndk version from master? I fixed some more issues in the build instructions and came across that problem. It seems stripping debug symbols is the only step that ignores ANDROID_NDK_HOME and specifically looks for $ANDROID_HOME/ndk/specified_ndk_version, so it's the only part that will fail with the wrong ndk version. ./gradlew stripBluetoothReleaseDebugSymbols --info shows the paths it checks for the ndk.

IzzySoft commented 5 days ago

By any chance, are you building the latest tag (ndk version 26.3.11579264) but using the ndk version from master?

Close. I built from the latest tag. I sometimes indeed forget to switch to the tag when checking (checking…) oof, straight hit: the tag specifies r26d, I've used 27, grmpf… OK, recipe adjusted, running another build now.

Does the NDK used change often? Then I'd mark your app's recipe for manual check should the build be RB now, with a note telling me where to look for the NDK to be updated (well, in the build.gradle.kts at the corresponding tag of course).

(build reached gradlew meanwhile – I catch myself something to drink before I check again…)

OK, looks much better: difference now is down to half a Megabyte now!

  -rw-r--r--  0.0 unx   157720 b-   157720 stor 1981-01-01 01:01:02 7c30fd53 lib/arm64-v8a/libjnidispatch.so
- -rw-r--r--  0.0 unx  1175000 b-  1175000 stor 1981-01-01 01:01:02 557494a7 lib/arm64-v8a/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1339000 b-  1339000 stor 1981-01-01 01:01:02 7968c852 lib/arm64-v8a/libopenscq30_android.so
  -rw-r--r--  0.0 unx     7252 b-     7252 stor 1981-01-01 01:01:02 9a714d3a lib/armeabi-v7a/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   112188 b-   112188 stor 1981-01-01 01:01:02 8f2cdb72 lib/armeabi-v7a/libjnidispatch.so
- -rw-r--r--  0.0 unx   872652 b-   872652 stor 1981-01-01 01:01:02 34a67c71 lib/armeabi-v7a/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1009576 b-  1009576 stor 1981-01-01 01:01:02 33b27c1e lib/armeabi-v7a/libopenscq30_android.so
  -rw-r--r--  0.0 unx   122784 b-   122784 stor 1981-01-01 01:01:02 4298d12a lib/armeabi/libjnidispatch.so
  -rw-r--r--  0.0 unx   150924 b-   150924 stor 1981-01-01 01:01:02 2d572a0c lib/mips/libjnidispatch.so
  -rw-r--r--  0.0 unx   141904 b-   141904 stor 1981-01-01 01:01:02 1a68d4c4 lib/mips64/libjnidispatch.so
  -rw-r--r--  0.0 unx     9284 b-     9284 stor 1981-01-01 01:01:02 3d9afc66 lib/x86/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   112108 b-   112108 stor 1981-01-01 01:01:02 76982304 lib/x86/libjnidispatch.so
- -rw-r--r--  0.0 unx  1211192 b-  1211192 stor 1981-01-01 01:01:02 9522fa41 lib/x86/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1416072 b-  1416072 stor 1981-01-01 01:01:02 97848477 lib/x86/libopenscq30_android.so
  -rw-r--r--  0.0 unx    10760 b-    10760 stor 1981-01-01 01:01:02 81bd88ae lib/x86_64/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   108632 b-   108632 stor 1981-01-01 01:01:02 e4a572de lib/x86_64/libjnidispatch.so
- -rw-r--r--  0.0 unx  1235640 b-  1235640 stor 1981-01-01 01:01:02 e90c5cc8 lib/x86_64/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1436800 b-  1436800 stor 1981-01-01 01:01:02 affc6ac7 lib/x86_64/libopenscq30_android.so
  -rw----     2.0 fat     1738 b-      782 defN 1981-01-01 01:01:02 d5ac4dc2 DebugProbesKt.bin

Took 10min as I forgot to change assembleRelease to assembleBluetoothRelease – so next run would probably be around 7 min. Still wonder where the remaining diff comes from now. Which version of rustup are you using? I couldn't find that mentioned. Build here was running with 1.25.1 (as that was used by another app, and I more-or-less copied and adjusted the rustup part from there). Let me retry with 1.27.1 (the latest one there), will report back when the build is through. And run again if you have another hint.

IzzySoft commented 5 days ago

OK, that didn't change much (except for build time being 1min less, around 9 min now). APK has the same size (to the byte) as it was with 1.25.1.

Oppzippy commented 5 days ago

My process for releases is:

  1. Build using github actions (android here: https://github.com/Oppzippy/OpenSCQ30/blob/v1.13.1/.github/workflows/build.yml#L142-L171)
  2. Download everything
  3. Sign the apk
  4. Sign everything with gpg
  5. Make a release on github and upload all of it

Rust is installed using dtolnay/rust-toolchain@stable, which uses the already installed version of rustup if available. The Github actions runner image currently has, and had at the time of OpenSCQ30 v1.13.1, rustup 1.27.1 installed (https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md#rust-tools).

I generally update the ndk version as new versions are added to github actions runner images so that I can have the workflow use the latest ndk. For convenience, I added a script at android/scripts/get-ndk-version.sh to print the current ndk version specified in build.gradle.kts.

Rust 1.80.1 was the latest stable version when OpenSCQ30 v1.13.1 was released, so that's the one that was used to build it.

Oppzippy commented 5 days ago

I can switch to building in a debian container if that would make things simpler.

IzzySoft commented 5 days ago

Build using github actions

That's what I oriented on and took most of the steps from. Differences here are: Debian bookworm instead of Ubuntu (should not make a difference in my experience), OpenJDK-17 instead of Temurin (rarely makes a difference – and as the diff lies in the .so files, it's unlikely to be the JDK I'd say), and installing rust via cloning the rustup repo and running their init script instead of rustup directly. No signing here of course (I don't have your keys). Full recipe looks like this:

repository: https://github.com/Oppzippy/OpenSCQ30.git
updates: releases
notes:
  - ends up with a bigger file (initially 64 MB due to NDK) than the expected 7.5 MB from upstream, see https://github.com/Oppzippy/OpenSCQ30/issues/139
  - use assembleBluetoothRelease to skip building the demo APK
versions:
  - tag: v1.13.1
    apks:
      - apk_pattern: openscq30_android\.apk
        apk_url: https://github.com/Oppzippy/OpenSCQ30/releases/download/v1.13.1/openscq30_android.apk
        build:
          - git clone https://github.com/rust-lang/rustup.git -b 1.27.1
          - export ANDROID_NDK=/opt/sdk/ndk/${PROVISIONING_NDK}
          - ${BUILD_REPO_DIR}/rustup/rustup-init.sh -y --target armv7-linux-androideabi --target aarch64-linux-android --target i686-linux-android --target x86_64-linux-android
          - source $HOME/.cargo/env
          - cargo install cargo-ndk
          - cd android
          - ./gradlew assembleBluetoothRelease
          - find . -name '*.apk'
          - mv app/build/outputs/apk/bluetooth/release/app-bluetooth-release-unsigned.apk /outputs/unsigned.apk
        build_cpus:
        build_home_dir: /build
        build_repo_dir: /build/repo
        build_timeout:
        build_user: build
        provisioning:
          android_home: /opt/sdk
          build_tools:
          cmake:
          cmdline_tools:
            version: '12.0'
            url: https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip
            sha256: 2d2d50857e4eb553af5a6dc3ad507a17adf43d115264b1afc116f95c92e5e258
          extra_packages:
            - make
            - g++
            - cmake
            - protobuf-compiler
          image: debian:bookworm-slim
          jdk: openjdk-17-jdk-headless
          ndk: 26.3.11579264
          platform:
          platform_tools:
          tools:
          verify_gradle_wrapper: true

And yeah, I could try with e.g. image: ubuntu:jammy as well, but I doubt that would change much. Would be different had you built using Fedora, or even Windows. But Debian and Ubuntu are close enough to each other.

Resulting APK here has 8420837 bytes (instead of the 7731308 bytes the APK from your releases has).

I added a script at android/scripts/get-ndk-version.sh to print the current ndk version specified in build.gradle.kts.

Thanks, but I'll need to took that up manually anyway as installing the APK is part of provisioning, so it cannot be done inside the build: part.

Rust 1.80.1 was the latest stable version when OpenSCQ30 v1.13.1 was released, so that's the one that was used to build it.

Rust is installed by rustup; I didn't check which version it grabbed. I can see to capture the log on the next run and attach it here (zipped), maybe something there catches your eye?

Oppzippy commented 5 days ago

The rust version seems to be the issue. When building with rust 1.80.1, I get within a few hundred bytes of the expected size. When I use the latest stable, which rustup will install by default, I get within a few hundred bytes of the size you're getting.

IzzySoft commented 5 days ago

Strange. So how can we tell rustup to install the version we need? --default-toolchain=1.80.1? I can try that. If we can work this one out, it might be a good idea to pin those versions e.g. via a config file:

rust: 1.80.1
rustup: 1.27.1

Those I then could fetch in the build recipe here to match what you've used.

Wow, that's indeed pretty close now:

  -rw-r--r--  0.0 unx   157720 b-   157720 stor 1981-01-01 01:01:02 7c30fd53 lib/arm64-v8a/libjnidispatch.so
- -rw-r--r--  0.0 unx  1175000 b-  1175000 stor 1981-01-01 01:01:02 557494a7 lib/arm64-v8a/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1174504 b-  1174504 stor 1981-01-01 01:01:02 9b47c368 lib/arm64-v8a/libopenscq30_android.so
  -rw-r--r--  0.0 unx     7252 b-     7252 stor 1981-01-01 01:01:02 9a714d3a lib/armeabi-v7a/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   112188 b-   112188 stor 1981-01-01 01:01:02 8f2cdb72 lib/armeabi-v7a/libjnidispatch.so
- -rw-r--r--  0.0 unx   872652 b-   872652 stor 1981-01-01 01:01:02 34a67c71 lib/armeabi-v7a/libopenscq30_android.so
+ -rw-r--r--  0.0 unx   871908 b-   871908 stor 1981-01-01 01:01:02 a8cb5df6 lib/armeabi-v7a/libopenscq30_android.so
  -rw-r--r--  0.0 unx   122784 b-   122784 stor 1981-01-01 01:01:02 4298d12a lib/armeabi/libjnidispatch.so
  -rw-r--r--  0.0 unx   150924 b-   150924 stor 1981-01-01 01:01:02 2d572a0c lib/mips/libjnidispatch.so
  -rw-r--r--  0.0 unx   141904 b-   141904 stor 1981-01-01 01:01:02 1a68d4c4 lib/mips64/libjnidispatch.so
  -rw-r--r--  0.0 unx     9284 b-     9284 stor 1981-01-01 01:01:02 3d9afc66 lib/x86/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   112108 b-   112108 stor 1981-01-01 01:01:02 76982304 lib/x86/libjnidispatch.so
- -rw-r--r--  0.0 unx  1211192 b-  1211192 stor 1981-01-01 01:01:02 9522fa41 lib/x86/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1210064 b-  1210064 stor 1981-01-01 01:01:02 a109365e lib/x86/libopenscq30_android.so
  -rw-r--r--  0.0 unx    10760 b-    10760 stor 1981-01-01 01:01:02 81bd88ae lib/x86_64/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   108632 b-   108632 stor 1981-01-01 01:01:02 e4a572de lib/x86_64/libjnidispatch.so
- -rw-r--r--  0.0 unx  1235640 b-  1235640 stor 1981-01-01 01:01:02 e90c5cc8 lib/x86_64/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1234600 b-  1234600 stor 1981-01-01 01:01:02 d0c2b4ae lib/x86_64/libopenscq30_android.so
  -rw----     2.0 fat     1738 b-      782 defN 1981-01-01 01:01:02 d5ac4dc2 DebugProbesKt.bin

Recipe:

build:
  - git clone https://github.com/rust-lang/rustup.git -b 1.27.1
  - export ANDROID_NDK=/opt/sdk/ndk/${PROVISIONING_NDK}
  - ${BUILD_REPO_DIR}/rustup/rustup-init.sh -y --default-toolchain=1.80.1 --target armv7-linux-androideabi --target aarch64-linux-android --target i686-linux-android --target x86_64-linux-android
  - source $HOME/.cargo/env
  - cargo install cargo-ndk
  - cd android
  - ./gradlew assembleBluetoothRelease
  - find . -name '*.apk'
  - mv app/build/outputs/apk/bluetooth/release/app-bluetooth-release-unsigned.apk /outputs/unsigned.apk

And now it gets funny. I've run strings over the arm64 libopenscq30_android.so of your and my APK, then diffed the output. Wanna see? strings.diff.gz For example, my APK includes which NDK was used (r26d), yours does not. Bummer. But see for yourself…

IzzySoft commented 5 days ago

PS: Your APK was built 2024-08-31, so rust 1.80.1 was not yet released (that came 5 days later), it must have been rust 1.80.0. I'll run again with that now…

Oppzippy commented 5 days ago

I think 1.80.1 should be correct, since it was tagged on August 8. Not sure why the github release says September 4. https://github.com/rust-lang/rust/tags

IzzySoft commented 5 days ago

1.80.0 didn't make much difference (in fact it added a few bytes on top, though not many). OK, then maybe the diff rings a bell with you… Maybe something similar with cargo, a la cargo install --version xxx? Are the versions of the dependencies pinned, or could it be I get some newer versions here now?

Oppzippy commented 5 days ago

cargo dependencies are pinned in Cargo.lock, so that shouldn't be an issue.

Ok, I think this part of the diff explains the problem.

+Android (11349228, +pgo, +bolt, +lto, -mlgo, based on r487747e) clang version 17.0.2 (https://android.googlesource.com/toolchain/llvm-project d9f89f4d16663d5012e5c09495f3b30ece3d2362)
+Linker: LLD 17.0.2
 rustc version 1.80.1 (3f5fd8dd4 2024-08-06)
-Android (12027248, +pgo, +bolt, +lto, +mlgo, based on r522817) clang version 18.0.1 (https://android.googlesource.com/toolchain/llvm-project d8003a456d14a3deb8054cdaa529ffbf02d9b262)
-Linker: LLD 18.0.1

I think v1.13.1 was compiled with a mix of two ndk versions. I realized the other day that when it was released, ndkVersion in build.gradle.kts wasn't set to the latest version, but I had github actions setting ANDROID_NDK_HOME to whatever the latest was. So the things that respect ANDROID_NDK_HOME used the latest version, and things that don't used the older version, leading to the mixed versions being used.

I ran a build just now if you want to compare against the d1ef7819136940ab16b04856a65a76fd4073a620 apk instead, which has that issue fixed. https://github.com/Oppzippy/OpenSCQ30/actions/runs/11745855902

edit: fix ANDROID_NDK_HOME typo

IzzySoft commented 2 days ago

Apologies for the delay, I had a guest this weekend and close to no time for looking at my computer…

Have been running the APK against the indicated commit, APK diff does not look much different unfortunately:

  -rw-r--r--  0.0 unx    10096 b-    10096 stor 1981-01-01 01:01:02 9734baa0 lib/arm64-v8a/libandroidx.graphics.path.so
- -rw-r--r--  0.0 unx   157800 b-   157800 stor 1981-01-01 01:01:02 786f7a35 lib/arm64-v8a/libjnidispatch.so
- -rw-r--r--  0.0 unx  1209768 b-  1209768 stor 1981-01-01 01:01:02 76d4ca7f lib/arm64-v8a/libopenscq30_android.so
+ -rw-r--r--  0.0 unx   168280 b-   168280 stor 1981-01-01 01:01:02 1b8c8cf5 lib/arm64-v8a/libjnidispatch.so
+ -rw-r--r--  0.0 unx 17526928 b- 17526928 stor 1981-01-01 01:01:02 4d80d3a1 lib/arm64-v8a/libopenscq30_android.so
  -rw-r--r--  0.0 unx     7252 b-     7252 stor 1981-01-01 01:01:02 9a714d3a lib/armeabi-v7a/libandroidx.graphics.path.so
- -rw-r--r--  0.0 unx   112248 b-   112248 stor 1981-01-01 01:01:02 29014005 lib/armeabi-v7a/libjnidispatch.so
- -rw-r--r--  0.0 unx   857116 b-   857116 stor 1981-01-01 01:01:02 60682a23 lib/armeabi-v7a/libopenscq30_android.so
+ -rw-r--r--  0.0 unx   122372 b-   122372 stor 1981-01-01 01:01:02 9534dcc0 lib/armeabi-v7a/libjnidispatch.so
+ -rw-r--r--  0.0 unx 14353020 b- 14353020 stor 1981-01-01 01:01:02 081a57fc lib/armeabi-v7a/libopenscq30_android.so
  -rw-r--r--  0.0 unx   122856 b-   122856 stor 1981-01-01 01:01:02 f07f9e68 lib/armeabi/libjnidispatch.so
  -rw-r--r--  0.0 unx   151000 b-   151000 stor 1981-01-01 01:01:02 6551d6ea lib/mips/libjnidispatch.so
  -rw-r--r--  0.0 unx   142016 b-   142016 stor 1981-01-01 01:01:02 f478dc20 lib/mips64/libjnidispatch.so
  -rw-r--r--  0.0 unx     9284 b-     9284 stor 1981-01-01 01:01:02 3d9afc66 lib/x86/libandroidx.graphics.path.so
- -rw-r--r--  0.0 unx   112164 b-   112164 stor 1981-01-01 01:01:02 7d966995 lib/x86/libjnidispatch.so
- -rw-r--r--  0.0 unx  1292124 b-  1292124 stor 1981-01-01 01:01:02 0496d3ac lib/x86/libopenscq30_android.so
+ -rw-r--r--  0.0 unx   120256 b-   120256 stor 1981-01-01 01:01:02 84023c8f lib/x86/libjnidispatch.so
+ -rw-r--r--  0.0 unx 14012680 b- 14012680 stor 1981-01-01 01:01:02 bb059457 lib/x86/libopenscq30_android.so
  -rw-r--r--  0.0 unx    10760 b-    10760 stor 1981-01-01 01:01:02 81bd88ae lib/x86_64/libandroidx.graphics.path.so
- -rw-r--r--  0.0 unx   108712 b-   108712 stor 1981-01-01 01:01:02 5aea9ee1 lib/x86_64/libjnidispatch.so
- -rw-r--r--  0.0 unx  1321888 b-  1321888 stor 1981-01-01 01:01:02 1b3d2b77 lib/x86_64/libopenscq30_android.so
+ -rw-r--r--  0.0 unx   118688 b-   118688 stor 1981-01-01 01:01:02 0f6cffbb lib/x86_64/libjnidispatch.so
+ -rw-r--r--  0.0 unx 16861088 b- 16861088 stor 1981-01-01 01:01:02 3db7a330 lib/x86_64/libopenscq30_android.so
  -rw----     2.0 fat     1738 b-      782 defN 1981-01-01 01:01:02 d5ac4dc2 DebugProbesKt.bin

Now I wanted to compare the output of strings libopenscq30_android.so again, but I decided I can skipp running diff – output of ls -l will tell you why:

-rw-rw-r-- 1 izzy izzy 5151284 Nov 11 10:15 local.strings
-rw-rw-r-- 1 izzy izzy   61203 Nov 11 10:15 upstream.strings

100 times more strings in my build it seems. Recipe was basically unchanged:

- git clone https://github.com/rust-lang/rustup.git -b 1.27.1
- export ANDROID_NDK=/opt/sdk/ndk/${PROVISIONING_NDK}
- ${BUILD_REPO_DIR}/rustup/rustup-init.sh -y --default-toolchain=1.80.1 --target armv7-linux-androideabi --target aarch64-linux-android --target i686-linux-android --target x86_64-linux-android
- source $HOME/.cargo/env
- cargo install cargo-ndk
- cd android
- ./gradlew assembleBluetoothRelease

Now I'm confused. Looked inside the strings files for clang version:

- Android (12470979, +pgo, +bolt, +lto, +mlgo, based on r522817c) clang version 18.0.3 (https://android.googlesource.com/toolchain/llvm-project d8003a456d14a3deb8054cdaa529ffbf02d9b262)
+ Android (11349228, +pgo, +bolt, +lto, -mlgo, based on r487747e) clang version 17.0.2 (https://android.googlesource.com/toolchain/llvm-project d9f89f4d16663d5012e5c09495f3b30ece3d2362)

Still a different version. I can specify a cmake version in the recipe file, but I have no idea how to specify clang. Or why my output is so much more verbose than yours for strings…

Oppzippy commented 2 days ago

Sorry, guess I should have specified. The master build is using rust 1.82 and NDK version 27.2.12479018, so when comparing against that rather than v1.13.1, you'll need to change the versions.

IzzySoft commented 1 day ago

Oof… yeah, with those many apps I deal with daily, being explicit in such cases is helpful :see_no_evil: ok, so this recipe:

- git clone https://github.com/rust-lang/rustup.git -b 1.27.1
- export ANDROID_NDK=/opt/sdk/ndk/${PROVISIONING_NDK}
- ${BUILD_REPO_DIR}/rustup/rustup-init.sh -y --default-toolchain=1.82.0 --target armv7-linux-androideabi --target aarch64-linux-android --target i686-linux-android --target x86_64-linux-android
- source $HOME/.cargo/env
- cargo install cargo-ndk
- cd android
- ./gradlew assembleBluetoothRelease

with ndk 27.2.12479018 and JDK 17.

  -rw-r--r--  0.0 unx   157800 b-   157800 stor 1981-01-01 01:01:02 786f7a35 lib/arm64-v8a/libjnidispatch.so
- -rw-r--r--  0.0 unx  1209768 b-  1209768 stor 1981-01-01 01:01:02 76d4ca7f lib/arm64-v8a/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1209176 b-  1209176 stor 1981-01-01 01:01:02 1d0135f0 lib/arm64-v8a/libopenscq30_android.so
  -rw-r--r--  0.0 unx     7252 b-     7252 stor 1981-01-01 01:01:02 9a714d3a lib/armeabi-v7a/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   112248 b-   112248 stor 1981-01-01 01:01:02 29014005 lib/armeabi-v7a/libjnidispatch.so
- -rw-r--r--  0.0 unx   857116 b-   857116 stor 1981-01-01 01:01:02 60682a23 lib/armeabi-v7a/libopenscq30_android.so
+ -rw-r--r--  0.0 unx   856540 b-   856540 stor 1981-01-01 01:01:02 c65e3528 lib/armeabi-v7a/libopenscq30_android.so
  -rw-r--r--  0.0 unx   122856 b-   122856 stor 1981-01-01 01:01:02 f07f9e68 lib/armeabi/libjnidispatch.so
  -rw-r--r--  0.0 unx   151000 b-   151000 stor 1981-01-01 01:01:02 6551d6ea lib/mips/libjnidispatch.so
  -rw-r--r--  0.0 unx   142016 b-   142016 stor 1981-01-01 01:01:02 f478dc20 lib/mips64/libjnidispatch.so
  -rw-r--r--  0.0 unx     9284 b-     9284 stor 1981-01-01 01:01:02 3d9afc66 lib/x86/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   112164 b-   112164 stor 1981-01-01 01:01:02 7d966995 lib/x86/libjnidispatch.so
- -rw-r--r--  0.0 unx  1292124 b-  1292124 stor 1981-01-01 01:01:02 0496d3ac lib/x86/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1291532 b-  1291532 stor 1981-01-01 01:01:02 f94d5813 lib/x86/libopenscq30_android.so
  -rw-r--r--  0.0 unx    10760 b-    10760 stor 1981-01-01 01:01:02 81bd88ae lib/x86_64/libandroidx.graphics.path.so
  -rw-r--r--  0.0 unx   108712 b-   108712 stor 1981-01-01 01:01:02 5aea9ee1 lib/x86_64/libjnidispatch.so
- -rw-r--r--  0.0 unx  1321888 b-  1321888 stor 1981-01-01 01:01:02 1b3d2b77 lib/x86_64/libopenscq30_android.so
+ -rw-r--r--  0.0 unx  1321312 b-  1321312 stor 1981-01-01 01:01:02 ddeb6ddc lib/x86_64/libopenscq30_android.so
  -rw----     2.0 fat     1738 b-      782 defN 1981-01-01 01:01:02 d5ac4dc2 DebugProbesKt.bin

Diff between the strings is 50k again.

- Android (12470979, +pgo, +bolt, +lto, +mlgo, based on r522817c) clang version 18.0.3 (https://android.googlesource.com/toolchain/llvm-project d8003a456d14a3deb8054cdaa529ffbf02d9b262)
+ Android (12470979, +pgo, +bolt, +lto, +mlgo, based on r522817c) clang version 18.0.3 (https://android.googlesource.com/toolchain/llvm-project d8003a456d14a3deb8054cdaa529ffbf02d9b262)

OK, that one seems to match this time. Something else must be amiss.

-Foreign pointer not set.  This is likely a uniffi bug./home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/uniffi_core-0.28.2/src/ffi/foreigncallbacks.rs/home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.41.0/src/sync/mpsc/list.rs
+Foreign pointer not set.  This is likely a uniffi bug./build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/uniffi_core-0.28.2/src/ffi/foreigncallbacks.rs/build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.41.0/src/sync/mpsc/list.rs

Ah, that gives me a clue this time, let me check…

build_home_dir: /build
build_repo_dir: /build/repo

Hm, and github actions, huh? So:

build_home_dir: /home/runner
build_repo_dir: /home/runner/work/OpenSCQ30/OpenSCQ30

should do the trick. Now I'm curious… Ha! Look what I got there:

    "upstream_signed_apk_sha256": "654639d50123fd2cfc78ff49b90cdb1e1bbeabc67fde18873fb27b5c5f8b2905",
    "built_unsigned_apk_sha256": "654639d50123fd2cfc78ff49b90cdb1e1bbeabc67fde18873fb27b5c5f8b2905",
    "signature_copied_apk_sha256": "654639d50123fd2cfc78ff49b90cdb1e1bbeabc67fde18873fb27b5c5f8b2905"

That means we succeeded with an RB (both signed APKs are byte-identical, thus showing the same hash) :partying_face: Any ETA for the next release, based upon this? :smiley:

Oppzippy commented 1 day ago

Nice, thanks for your work on this. There's not really anything major left for the next feature release, so it'll probably be in around a week or so.

IzzySoft commented 1 day ago

Cool! Please give me a ping then (err, I guess as this issue is solved, closing it once the release is up would serve that purpose as well). Glad we finally figured it out – and thanks a lot for all your help and patience with the process!!! :star_struck: