ndk-build only needs java/javac, not GUI capabilities.
Switching to jdk_headless drops ~257 MB of unnecessary
desktop dependencies (GTK+3, icu4c, harfbuzz, cups, systemd)
from the closure.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This lets us stop hardcoding platforms and start filtering for which
archives have sources, which is the most accurate way to do it.
Tested on x86_64-linux, aarch64-linux, and aarch64-darwin.
We can figure out the latest version for every package in mkrepo.rb,
instead of repeating ourselves in compose-android-packages.
Track the latest non-preview versions of all packages by default, and
remove version hardcoding everywhere. Enable the update script.
androidenv: apply numinit patch to have a nice error message
androidenv handle unsupported systems, and make tests running by default!
androidenv run nixfmt
androidenv: support emulator/systemimages/NDK only for certain systems
androidenv: apply nixfmt
androidenv: give a warning if archive doesn't exist
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Fixes#298285, alternative to #300386.
As suggested in #298285 `lib64` was renamed to `lib`, so just doing the same
as for `lib64` seems to fix the issue.
See also recent discussion in #300386.
Use of binaries from NDK `toolchains` has been broken by following PR:
* https://github.com/NixOS/nixpkgs/pull/195752
I'm splitting the patchInstructions to run the ELF patching only on Linux.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This is supposed to fix an issue caused by this PR:
https://github.com/NixOS/nixpkgs/pull/163924
Which made `autoPatchelfHook` available only on Linux, resulting in
builds of Android packages failing with:
```
error: Package ‘auto-patchelf-hook’ in /nix/store/...-nixpkgs-source/pkgs/build-support/trivial-builders.nix:73
is not supported on ‘x86_64-darwin’, refusing to evaluate.
```
Signed-off-by: Jakub Sokołowski <jakub@status.im>
The script make_standalone_toolchain.py autogenerates some shell scripts
when invoked. These scripts have a hardcoded shebang of '#!/bin/bash'.
The generated scripts obviously do not work in a Nix environment. This
commit makes sure the scripts have the correct shebang.
androidenv did not previously write license files, which caused certain
gradle-based Android tools to fail. Restructure androidenv's list of
Android packages into a single repo.json file to prevent duplication
and enable us to extract the EULA texts, which we then hash with
builtins.hashString to produce the license files that Android gradle
tools look for.
Remove includeDocs and lldbVersions, as these have been removed
from the Android package repositories.
Improve documentation and examples.
We just need jdk for this script that helps set up toolchains. The
script might need to know about the target platform, but the interpreter
that runs it (or part of it) doesn't.
