Skip to content

android-tools: init at 31.0.0p1#124992

Merged
primeos merged 1 commit intoNixOS:masterfrom
primeos:android-tools
Jun 2, 2021
Merged

android-tools: init at 31.0.0p1#124992
primeos merged 1 commit intoNixOS:masterfrom
primeos:android-tools

Conversation

@primeos
Copy link
Member

@primeos primeos commented May 30, 2021

TODO:
[ 52%] Built target fipsmodule
[ 52%] Generating chacha/chacha-x86_64.S
[ 52%] Generating test/trampoline-x86_64.S
[ 52%] Generating cipher_extra/aes128gcmsiv-x86_64.S
[ 52%] Generating cipher_extra/chacha20_poly1305_x86_64.S
[ 52%] Generating err_data.c
go: golang.org/x/[email protected]: Get "https://proxy.golang.org/golang.org/x/crypto/@v/v0.0.0-20200622213623-75b288015ac9.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:56418->[::1]:53: read: connection refused
make[2]: *** [vendor/boringssl/crypto/CMakeFiles/crypto.dir/build.make:104: vendor/boringssl/crypto/err_data.c] Error 1
make[2]: *** Deleting file 'vendor/boringssl/crypto/err_data.c'
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:1351: vendor/boringssl/crypto/CMakeFiles/crypto.dir/all] Error 2
make: *** [Makefile:171: all] Error 2
builder for '/nix/store/yib15nh8kzgrf94ijbgsjmbppcs59jij-android-tools-31.0.0p1.drv' failed with exit code 2
error: build of '/nix/store/yib15nh8kzgrf94ijbgsjmbppcs59jij-android-tools-31.0.0p1.drv' failed

Motivation for this change

See #75603 and #75603 (comment). This let's us finally build the Android tools from source.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Added a release notes entry if the change is major or breaking
  • Fits CONTRIBUTING.md.

@primeos
Copy link
Member Author

primeos commented May 30, 2021

The good news is that only the vendored BoringSSL seems to use Go modules (./vendor/boringssl/go.sum) but unfortunately we seem to lack an equivalent of #112500 for Go. We could use a workaround but since this'll likely affect more and more Nixpkgs packages it would be nice if we could implement a general abstraction. I'll open a dedicated issue for that. Edit: #124993.

@musfay
Copy link
Contributor

musfay commented May 30, 2021

@primeos simg2img, img2simg and append2simg binaries are already provided by simg2img package.

@ofborg ofborg bot added 8.has: package (new) This PR adds a new package 11.by: package-maintainer This PR was created by a maintainer of all the package it changes. 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. 10.rebuild-linux: 1 This PR causes 1 package to rebuild on Linux. labels May 30, 2021
@primeos
Copy link
Member Author

primeos commented May 30, 2021

@musfay good to know. We should probably still use the bundled ones to avoid version conflicts (if they're used by the other tools) but then we should at least use lowPrio to avoid conflicts with the simg2img package or move those binaries out of bin/.

pname = "android-tools";
version = "31.0.0p1";

src = fetchurl {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be using fetchFromGitHub?

Copy link
Contributor

@musfay musfay May 31, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to use release tarball as the repo only have build-system and documentation. Upstream doesn't vendorize platform-tools source code in repo. They use CPack to create tarball from used source files.
https://github.com/nmeum/android-tools/tree/master/vendor

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How many sources would we need to declare in Nix to achieve the same? I'd prefer if all sources were declared transparently instead of relying on an opaque tarball.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well in that case we need to checkout some of AOSP repositories. Those repositories are actually HUGE and Google doesn't provide snapshots from tags. Checking out repositories takes nearly 1 hour on my computer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole tree is obviously huge but we shouldn't need all of it. That's why I was asking.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can declare the source files but there is 13-14 repos and lots of files all aroud the tree. Leaving the tracking job to CPack would be much easier. I don't agree tarballs are opaque as you can reproduce them. We can create our tarballs or vendorize CPack output in a repository.

Copy link
Contributor

@musfay musfay May 31, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it legally OK if we mirror some of Google's repositories on other platforms like this one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is 13-14 repos

Yeah, that's a bit much.

I don't agree tarballs are opaque as you can reproduce them.

The problem with that is that the reproduction is not transparent and in this case probably not even reproducible at a different point in time.
You don't know anything about how CPack was made nor which version of the sources it fetched.
Google's repo doesn't have a single "revision" or an equivalent; it's an aggregation of whatever happens to be at the top of a few hundred repos at a certain point in time.
It'd only become transparent if the generation was declared in Nix because then you'd have to lock the exact revision and hash of every included repo.

As I said though, too many repos. I was hoping for, like, 5 which would've been a feasible amount to maintain ourselves.

Is it legally OK if we mirror some of Google's repositories

The APL2 allows you to redistribute source code in any way you like but, why?

Copy link
Contributor

@musfay musfay Jun 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree tarballs are opaque as you can reproduce them.

The problem with that is that the reproduction is not transparent and in this case probably not even reproducible at a different point in time.
You don't know anything about how CPack was made nor which version of the sources it fetched.
Google's repo doesn't have a single "revision" or an equivalent; it's an aggregation of whatever happens to be at the top of a few hundred repos at a certain point in time.
It'd only become transparent if the generation was declared in Nix because then you'd have to lock the exact revision and hash of every included repo.

It makes sense now. Thanks for the definition!

As I said though, too many repos. I was hoping for, like, 5 which would've been a feasible amount to maintain ourselves.

Yep there is lots of repos.

Is it legally OK if we mirror some of Google's repositories

The APL2 allows you to redistribute source code in any way you like but, why?

Just asked, offtopic.

@primeos
Copy link
Member Author

primeos commented May 31, 2021

I haven't done any extensive testing yet but while implementing a workaround for fetching the Go modules I've noticed that setting GOFLAGS = [ "-mod=vendor" ]; is enough and that the Go modules are apparently not required (at least the build succeeds without them).

@primeos primeos marked this pull request as ready for review May 31, 2021 20:13
@primeos primeos requested a review from alyssais as a code owner May 31, 2021 20:31
@musfay
Copy link
Contributor

musfay commented Jun 1, 2021

failed to initialize build cache at /homeless-shelter/.cache/go-build: mkdir /homeless-shelter: permission denied
make[2]: *** [vendor/boringssl/crypto/CMakeFiles/crypto.dir/build.make:104: vendor/boringssl/crypto/err_data.c] Error 1
make[2]: *** Deleting file 'vendor/boringssl/crypto/err_data.c'
make[1]: *** [CMakeFiles/Makefile2:1351: vendor/boringssl/crypto/CMakeFiles/crypto.dir/all] Error 2
make: *** [Makefile:171: all] Error 2
builder for '/nix/store/7zfz1im7k03y87hb051mg7b67hr5irrn-android-tools-31.0.0p1.drv' failed with exit code 2
error: build of '/nix/store/7zfz1im7k03y87hb051mg7b67hr5irrn-android-tools-31.0.0p1.drv' failed

Oops.

@Atemu
Copy link
Member

Atemu commented Jun 1, 2021

You'll probably have to set some Go environment variable to use /build for the build instead of $HOME.

@musfay
Copy link
Contributor

musfay commented Jun 1, 2021

Ofborg fails too. We can create adb-boringssl package with required revision of boringssl as it's only required by adb. Using nixpkgs's boringssl also fails.

@primeos
Copy link
Member Author

primeos commented Jun 1, 2021

Thanks, it looks like the Nix build sandboxing on my non-NixOS build host isn't properly working (anymore?).
I've built it on a NixOS host now.

Edit: Force pushed again to fix the AArch64 build:

[ 50%] Building C object vendor/CMakeFiles/libext2fs.dir/e2fsprogs/misc/create_inode.c.o
In file included from /build/android-tools-31.0.0p1/vendor/adb/client/file_sync_client.cpp:46:
/build/android-tools-31.0.0p1/vendor/adb/compression_utils.h:21:10: fatal error: span: No such file or directory
   21 | #include <span>
      |          ^~~~~~
compilation terminated.
make[2]: *** [vendor/CMakeFiles/libadb.dir/build.make:205: vendor/CMakeFiles/libadb.dir/adb/client/file_sync_client.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

@musfay
Copy link
Contributor

musfay commented Jun 2, 2021

I can confirm that everything works as expected. Flashed some images via fastboot. Tested adb through WiFi, pushed some files, had no issues.

lowPrio is used to avoid collisions with the simg2img package.
Licensing information is in share/licenses/android-tools/AOSP_LICENSE.
@ofborg ofborg bot added the 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. label Jun 2, 2021
@ofborg ofborg bot removed 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. labels Jun 2, 2021
@primeos
Copy link
Member Author

primeos commented Jun 2, 2021

@musfay thanks for the testing! I've also used adb today and didn't notice any issues.

I'll merge this now (it works, we finally have a FLOSS package for adb and fastboot, and we can still improve the Nixpkgs expressions later - e.g. to generate the tarballs in a reproducible way).

Edit: The Darwin build failure (just for future reference):
https://logs.nix.ci/?key=nixos/nixpkgs.124992&attempt_id=796eb353-3873-4198-a1b7-1763192f1153

[ 20%] Building CXX object vendor/CMakeFiles/liblog.dir/logging/liblog/logger_write.cpp.o
/tmp/nix-build-android-tools-31.0.0p1.drv-0/android-tools-31.0.0p1/vendor/logging/liblog/logger_write.cpp:140:36: error: use of undeclared identifier 'getprogname'
  static std::string default_tag = getprogname();
                                   ^
/tmp/nix-build-android-tools-31.0.0p1.drv-0/android-tools-31.0.0p1/vendor/logging/liblog/logger_write.cpp:235:3: error: use of undeclared identifier 'pthread_threadid_np'
  pthread_threadid_np(NULL, &tid);
  ^
2 errors generated.
make[2]: *** [vendor/CMakeFiles/liblog.dir/build.make:134: vendor/CMakeFiles/liblog.dir/logging/liblog/logger_write.cpp.o] Error 1

@primeos primeos merged commit ed8115e into NixOS:master Jun 2, 2021
@Atemu
Copy link
Member

Atemu commented Jun 2, 2021

Should we update programs.adb to use adb from here instead?

@primeos
Copy link
Member Author

primeos commented Jun 2, 2021

Sounds like a good idea to me (cc @Mic92).
Interestingly androidenv.androidPkgs_9_0.platform-tools doesn't have meta.license set which seems like a bug...

analog = callPackage ../tools/admin/analog {};

android-tools = lowPrio (callPackage ../tools/misc/android-tools {
stdenv = if stdenv.targetPlatform.isAarch64 then gcc10Stdenv else stdenv;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was likely required for #124992 (comment) ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

8.has: package (new) This PR adds a new package 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. 10.rebuild-linux: 1 This PR causes 1 package to rebuild on Linux. 11.by: package-maintainer This PR was created by a maintainer of all the package it changes.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants