Build fails for 1.1.0+0680

[IzzySoft]

Not sure if the required build steps changed (it worked for the release in January – but neither the Readme nor the GHA have been changed since 10/2025), but…

go: downloading github.com/pion/transport/v2 v2.2.1
go: downloading gopkg.in/yaml.v2 v2.4.0
web/frps/embed.go:11:12: pattern dist: no matching files found

> Task :app:buildArm64FrpClientCore FAILED
warning: both GOPATH and GOROOT are the same directory (/home/runner/go); see https://go.dev/wiki/InstallTroubleshooting
go: downloading github.com/rodaine/table v1.2.0
go: downloading github.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5
web/frpc/embed.go:11:12: pattern dist: no matching files found

FAILURE: Build completed with 6 failures.

1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:npmInstServer'.
> Process 'command 'env'' finished with non-zero exit value 127

2: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:npmMakeServer'.
> Process 'command 'make'' finished with non-zero exit value 2

3: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:npmInstClient'.
> Process 'command 'env'' finished with non-zero exit value 127

4: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:npmMakeClient'.
> Process 'command 'make'' finished with non-zero exit value 2

5: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:buildArm64FrpServerCore'.
> Process 'command 'env'' finished with non-zero exit value 1

6: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:buildArm64FrpClientCore'.
> Process 'command 'env'' finished with non-zero exit value 1

That crash happens in make arm64. Not sure where you built that app – but certainly not with the GHA here. Digging through the logs, I see several dependencies seem to be missing – maybe time to update the build instructions/steps?

> Task :app:npmInstServer FAILED
env: 'npm': No such file or directory

...

> Task :app:npmInstClient FAILED
env: 'npm': No such file or directory

So at least some Node stuff seems to be required. Amending the build recipe by inserting the following before make purge_sdk:

          - wget -q -O /tmp/nodejs-lts.zip -- https://nodejs.org/dist/v24.15.0/node-v24.15.0-linux-x64.tar.xz
          - sha256sum -c <<< '472655581fb851559730c48763e0c9d3bc25975c59d518003fc0849d3e4ba0f6  /tmp/nodejs-lts.zip'
          - tar xf /tmp/nodejs-lts.zip -C /opt
          - export PATH="${PATH}:/opt/node-v24.15.0-linux-x64/bin:${HOME}/.node/bin"
          - npm config set prefix "${HOME}/.node"

results in a successful build – but the resulting APK does not matching yours (which I almost expected – as it was VERY unlikely your GHA would have succeeded there): native libraries differ, most likely because the build path differs. OK, let's check the diffoscope:

So you somehow embed the git status – which differs in your case and ours, and always will. So this breaks RB, effectively. Can you turn that off? Hm, something nags me there, like a deja vu – now, where did I see vcs.modified before? 🤔

[IzzySoft]

As we have no solution there without your help, we now had to commit the results: 1.1.0+0680 will now carry the warning shield of a failed RB, sorry… Please take care to keep that vcs.* stuff out for the next releases.

[donmor]

New frp versions since 0.67.0 have webui embedded (built with nodejs). I'm not sure if this breaks the reproducibility.

Edit: Yes, I recalled that some files could be generated or modified during npm install (not in .gitignore), making the working tree dirty.

[donmor]

It seems to be an upstream problem since 0.68.0. I've reported it in fatedier/frp#5303 .

[donmor]

Rolled back to frp v0.67.0 (tag 1.1.0+0670)

[IzzySoft]

Well, 1.1.0+680 was already rolled out. Shall we remove that again? Is there a problem beside the RB one?

[donmor]

Welp, I have no idea (frp 0.68.0 itself has no problem; there've been 0.68.1 but it's not buildable for android, dependency problem)

I keep both 1.1.0+0680/0670

[IzzySoft]

One interesting fact, though not directly related:

  "version_codes": {
    "100006": [
      "1.0.6+0650"
    ],
    "100007": [
      "1.0.7+0650",
      "1.0.7+0660"
    ],
    "101000": [
      "1.1.0+0670",
      "1.1.0+0680"
    ]
  },

That means, you sometimes forget to increase versionCode. And I don't get your versionName logic: 670 is newer than 680? The latter dates 2026-04-28, the former 2026-05-01. Please, take a look at semantic versioning. That is best practice, and that is what our updater here uses to look for newer releases. Due to the size of your APK, we only carry a single release – which currently is 680 🤷‍♂️

[sinaqwers0-tech]

https://github.com/fatedier/frp

[sinaqwers0-tech]

Rolled back to frp v0.67.0 (tag 1.1.0+0670)

[IzzySoft]

I'm not sure what you mean by your comments. You cannot use the same versionCode for multiple releases, they need to be "dedicated". And if downgrading to an earlier FRP means your versionName and tag name will be lower, such a release won't be picked up by our updater – which then considers it "older than what we already have". Best practice for versionName (and tag names) is to follow semantic versioning.

[donmor]

version 1.1.0 / versionCode 101000 is for DroidFRPD itself. Different apks with same versionCode but different frp version (+0680 part) can replace each other (in case frp itself has issues, it can be downgraded without losing data), this is intended.

[IzzySoft]

this is intended.

But not working for app stores and repositories, where <applicationId>_<versionCode> are unique keys, sorry. This combination defines exactly 1 APK. So if such an APK is already there, another one with the same identifier is rejected ("already here"). So "first come, first served". Which means: if you make a newer release, but reuse versionCode, you just put additional load on our servers (the APK from the new release would be pulled on each run, just to be thrown away – so when we notice such, we move the corresponding app from the daily to the monthly update track, to avoid such resource waste). If however the tag name "decreases" (e.g. from 1.1.0+0680 to 1.1.0+0670), our repo updater ignores that tag (but our builder still fetches it once). Still resource waste, as we needlessly build that release for RB, while not shipping the corresponding APK.

[donmor]

Okay... So the versionCode have to be bumped to trigger the updater, but there's no much things to do with java part of DroidFRPD, and if bump versionCode with nothing changed, it just causes being impossible to reinstall different frp version without uninstalling the whole app (loses data)...

[IzzySoft]

And if you set a "lower" tag name, it won't be picked up by our repo updater anyway. Can't be helped, that's the way it is designed. Disabling downgrades was not our work…