gradle wrapper outdated?

[IzzySoft]

your gradle-wrapper.properties states

 distributionUrl=https\://services.gradle.org/distributions/gradle-3.3-all.zip

which cannot be true, as your project uses JDK 17, which is not supported by that ancient gradle version. Could it be the wrapper is outdated, and you just forgot to replace it? You can impossibly have compiled the app with that. According to your workflow you use JDK 18 with that gradle even – I cannot fathom how that should work 😉 Java 17 would require gradle 7.3+, Java 18 even 7.5+.

Any chance you could update the gradle wrapper? Probably the change here from 7.0 to 3.3 was a typo, and you meant 8.3? Thanks in advance!

PS: I've tried building v1.5.1 with injecting gradle 8.9, but the build failed:

> Could not resolve all artifacts for configuration ':classpath'.
   > Could not find com.android.tools.build:gradle:2.2.3.
     Searched in the following locations:
       - https://jcenter.bintray.com/com/android/tools/build/gradle/2.2.3/gradle-2.2.3.pom
     Required by:
         project :

JCenter is dead. Maybe you can use a newer version of the plugin? There are several available from Google's Maven.

[nikita-yfh]

Can you make pull request?

[IzzySoft]

I'm no Android dev, sorry – I just try to compile from source and interpret the errors. I don't even know which gradle version you'd need (or used to compile the current APK).

For some background: At IzzyOnDroid (where your app is currently listed – be welcome to pick a badge and link there e.g. from your Readme) we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). For that, we need to be able to compile from your source.

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]

It looks like that workflow was never run. And Android Gradle Plugin 2.2.3 -- which I doubt was ever on JCenter as Google uses their own maven repo -- is from 2016/2017. That would match Gradle 3.3 (presumably built with Java 8). I also see minSdkVersion 12 and targetSdkVersion 20, suggesting the app is indeed using a pretty old toolchain. Which likely means Reproducible Builds won't be possible.

[IzzySoft]

Thanks Fay!

@nikita-yfh any plans to lift that up? If not, I'd say we have to drop the app from our RB queue (RB is not mandatory, just strongly recommended). No bad feelings if that's what you prefer, though a matching update would be what we prefer 😉

[nikita-yfh]

I have deleted the new PR from the history.
Then I was sure that the new PR would not break anything, and after that I did not check compilation, it's my mistake.
This version must compile.

[IzzySoft]

I don't see a new commit – maybe you forgot to push? Also, we'd then need a matching APK (built from that commit) to compare against. Thanks!

[IzzySoft]

PS, as there might be a slight misunderstanding: we were not using any Github CI there. We use this recipe:

---
repository: https://github.com/nikita-yfh/android-adb-tools.git
updates: releases
versions:
  - tag: 1.5.1
    apks:
      - apk_pattern: apprelease\.apk
        apk_url: https://github.com/nikita-yfh/android-adb-tools/releases/download/1.5.1/app-release.apk
        build:
          - ./gradlew assembleRelease
          - find . -name '*.apk'
          - mv app/build/outputs/apk/release/*unsigned.apk /outputs/unsigned.apk
        build_home_dir: /build
        build_repo_dir: /build/repo
        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: []
          image: debian:bookworm-slim
          jdk: openjdk-17-jdk-headless
          ndk:
          platform:
          platform_tools:
          tools:
          verify_gradle_wrapper: true

with rbtlog as the task is about confirming Reproducible Builds, also see Reproducible Builds, special client support and more at IzzyOnDroid (as mentioned above).

[nikita-yfh]

I didn't make a new commit, I just rolled back to delete broken commits.

Are you sure about using the noroot branch? The functionality in it is far from fully implemented. The oldroot version works completely

[nikita-yfh]

APK build for noroot branch is coming soon...

[IzzySoft]

Are you sure about using the noroot branch?

We do not use branches directly, but just follow the tag. We build from the commit the tag points to. And yes, tag points to e36f1e0 which is the top of the noroot branch right now. And where the gradle wrapper points to a 10 year old gradle version which cannot work with JDK 17 as it doesn't know of it, see my initial post. You cannot have build the APK at that release with that wrapper.

[obfusk]

which cannot work with JDK 17

Indeed, the workflow -- which never ran AFAICT -- was likely broken.

You cannot have build the APK at that release with that wrapper.

Not with Java 17. I'm assuming 8 was used. Which should work, except for the missing dependencies.

[obfusk]

tag points to e36f1e0 which is the top of the noroot branch right now.

Which strongly suggests the tag is not pointing to the commit from which the APK was built. That seems to be the oldroot branch.

[IzzySoft]

I'm assuming 8 was used.

That would even work with gradle-3.3, yes (it's the newest JDK supported by that gradle version). And the missing dependency most likely locally cached, would be my guess…

[nikita-yfh]

Which strongly suggests the tag is not pointing to the commit from which the APK was built. That seems to be the oldroot branch.

I don't understand how did this happen. All of this releases are from oldroot branch

How I can fix it?

[IzzySoft]

First, to update your gradle-wrapper properly:

Open a terminal in your project’s root directory. Run the following command to update the wrapper JAR and other related files:

./gradlew wrapper --gradle-version [VERSION]

Replace [VERSION] with the latest Gradle version (e.g., 8.10.1).

And btw: it's outdated in both branches – both have gradle 3.3.

---

I don't understand how did this happen.

As for the tag and the APKs: Tag 1.5.1 points to commit e36f1e0 – which is the top of the noroot branch and was committed in 11/2022. The data on top of this screenshot is from when the tag was created:

The APK was rather built from commit 7953bb7 – as that's where the version was adjusted accordingly:

And that commit is from 12/2023, matching the date of the APK and of the tag. So you've just tagged the wrong commit – most likely you had temporarily checked out the other branch and then just tagged "where you were".

How I can fix it?

By taking care what branch you are in when building / committing, mostly: having everything tested for release, make sure to commit the latest changes, have a clean tree, tag that and right after that build your release APK (it's fine to build before tagging, but make sure to change NOTHING between your last commit and creating the tag except for building the APK, so everything is in sync.

---

Nikita, one more thing. And please don't get me wrong with this question – absolutely no offense meant, but this is about security. Your app needs root powers – your Readme clearly states that. How fit are you in that area? Are there any risks involved for those using your app? As maintainer of the repo distributing your app I must ask this question at this point, sorry. It's totally fine to have gaps (I openly admit mine too when being asked – Fay certainly can confirm that, and she taught me a lot). If there are risks involved, they should be named – that's also what disclaimers are for. To protect both, those using your app – and you as well.

While the license (here: MIT, third paragraph) includes a generic disclaimer ("… WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED …"), people accept that as "salvatory clause". If there are specific risks one would not expect, they should better be pointed out – especially with a root app. </teacher-mode> Again, no offense meant. My worries might be totally unwarranted, and you probably just got confused by git…

[nikita-yfh]

https://github.com/nikita-yfh/android-adb-tools/releases/tag/1.5.2

[nikita-yfh]

Are there any risks involved for those using your app?

We need root only for launching Adb and Fastboot binaries. Basic actions in app can't damage your system, because it doesn't use host file system except for /sdcard and app directory in /data/data.
Of course, you can damage your system by typing " rm -rf /* " in the app command line... Therefore, it is assumed that the user will not intentionally break the device.

[IzzySoft]

With 1.5.2, your app unlisted itself from IzzyOnDroid:

Binary files /web/ftp/repo/fdroid/repo/ru.nikita.adb_6.apk and /web/ftp/repo/fdroid/repo/ru.nikita.adb_1.5.2.apk differ
2024-09-11 19:48:31,677 ERROR: No signing certificates found in repo/ru.nikita.adb_6.apk
2024-09-11 19:48:31,677 WARNING: Skipping 'ru.nikita.adb_6.apk' with invalid signature!
2024-09-11 19:50:44,149 WARNING: Found graphics without metadata for app "ru.nikita.adb"!

This means you forgot to increase versionCode and forgot to sign the APK – so the unsigned APK overwrote the last version present. Unsigned APKs are not accepted in the repo, so nothing remained to be listed ("without metadata" means there was no APK left and thus the metadata have been dismissed)…

As for root: my question was less about why the app might need root. I was more concerned about your experience with programming in general – seeing how many things went wrong here: gradle wrapper being out of sync. you refer to a workflow that was never run. your release tag points to the wrong branch. the app does not build. you forget to increase versionCode and signing, too… Mistakes happen to the best of us, but they should not sum up that much. So again, honest question asking for a honest answer: how much do we need to be concerned? There is no shame in being a beginner, we all have been beginners once. But with an app that uses root powers, this must be transparent – not everyone is willing to take extra risks there for their main (or only) device. And once more: no offense meant, but as maintainer of IzzyOnDroid I must make sure.

[nikita-yfh]

Mistakes happen to the best of us, but they should not sum up that much.

Two years ago, when I was still writing this application, I did not make such mistakes. Now I'm working on a completely different project, and I haven't worked with Android for more than a year. I hope you will understand me :)

So again, honest question asking for a honest answer: how much do we need to be concerned?

On the 4pda forum my app has more then 2k downloads, and no one had a problem with that. Probably the only serious problem was that the ADB daemon does not run correctly on some fairly old devices. I still haven't been able to solve this problem. But I can't install minSdk correctly either, since the application works fine on many older devices. I am sure that there is no point in worrying that the ADB or Fastboot binary will accidentally break the system on its own.

So, I started working on the noroot version because the Android API should work the same on any device and there is no need for ADB/Fastboot binaries. But it's still not ready.

I've already updated the latest version 1.5.2 with a signed APK.