AAPT2 Daemon not starting on Apple Silicon

[AddyVeerendra]

I recently purchased a new M4 MacBook to replace my old Intel one, and used it to write FTC programs. It was working until a few days ago, and now I have a problem where everytime I try to run a Gradle build, the AAPT2 Daemon doesn't start. I believe it could be because of the hardware switch, since I tried the build on a Windows x86 laptop and it worked. However, building did work when I first got this laptop, and they only broke after I updated Android Studio and/or the SDK. I'm currently using Ladybug 2024.2.1 Patch 3.

I tried cleaning and rebuilding caches, fresh installing Android Studio and fiddling with Rosetta 2, but nothing worked. Has anyone else faced this problem? I'm using JBR 17 for the Gradle JDK.

[alan412]

I am successfully building FTC programs on Apple Silicon on Ladybug Patch 3. I am also using the JBR 17.0.11 that comes with Android Studio for Gradle.

The path is /Applications/Android Studio.app/Contents/jbr/Contents/Home

[alan412]

What version of the SDK are you using? We had to do an emergency release of 10.1.1 in November because older versions wouldn't work with Ladybug.

[AddyVeerendra]

Most recent one, 10.1.1

[alan412]

If you want to share your Android Studio Project, I'll try to build it and let you know if I have any problems.

[AddyVeerendra]

Sure, I have attached the GitHub link to our project below. However, I have also tried building the original barebones FTC SDK and it also failed to build due to the same issue. Would you like me to send any settings as well?

https://github.com/AddyVeerendra/TEAM21689_INTO_THE_DEEP

[AddyVeerendra]

I am also aware that the dependencies classpath in build.gradle is 8.7.3. I tried building with 8.7.0 too but to no avail.

[alan412]

Shockingly enough, I could build it just fine. If you send me your settings I can compare them to mine and see how different they are.

…

--Alan

On Sat, Dec 28, 2024 at 5:43 PM Addy Veerendra ***@***.***> wrote: I am also aware that the dependencies classpath in build.gradle is 8.7.3. I tried building with 8.7.0 too but to no avail. — Reply to this email directly, view it on GitHub <#1380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF3Y74QQALIXN2OROUWUYL2H4SSHAVCNFSM6AAAAABUJ2M4UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGUZDGOBVGQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[dmssargent]

It sounds like your Android SDK installation isn’t quite right, given aapt2 isn’t launching. I need the full trace to say why, but it could be the tool isn’t quite right.

The SDK is managed separately from Android Studio, so removing Android Studio, doesn’t delete the Android SDK.

In Android Studio, can you open the SDK Manager (https://developer.android.com/studio/intro/update?hl=en#sdk-manager) and check the Show Package Details? Under the Build Tools Section, multiple versions should appear. Note and uncheck whatever is selected and for now, download the latest version or the second latest version if the latest was checked.

That should force the old version to be removed and install a candidate version of the build-tools.

If you get an error about a version mismatch, install the suggested version. If you get an error about xattrs, close Android Studio, allow Full Disk Access and Developer Tools in System Settings and restart your computer to close any development process that could still be open. If you get an error about CPU, you can rename the entire Android SDK directory and restart Android Studio.

[AddyVeerendra]

@dmssargent Thanks for the reply. I installed the latest version (36.0.0-rc3), but it seems that when I build on the SDK, it defaults to 34.0.0 and just uses that instead. I have attached a screenshot below showing the defaulting process, as well as some other warnings I received. Is there anything to be concerned about?

[AddyVeerendra]

@alan412 Here are some settings from Android Studio. I also switched to JBR 21 to see if that would change anything, although it didn't.

Android Studio

Android Studio Ladybug | 2024.2.1 Patch 3
Build #AI-242.23339.11.2421.12700392, built on November 22, 2024
Runtime version: 21.0.3+-79915917-b509.11 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Toolkit: sun.lwawt.macosx.LWCToolkit
macOS 15.1.1
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 2048M
Cores: 10
Metal Rendering is ON
Registry:
ide.experimental.ui=true
i18n.locale=
terminal.new.ui=true

Gradle

Distribution: Wrapper
Gradle JDK: GRADLE_JAVA_LOCAL_HOME (JBR 21.0.3 aarch64)
Path: /Applications/Android \Studio.app/Contents/jbr/Contents/Home

Teamcode Module

FtcRobotController Module

Same as Teamcode module but without ndk version

[AddyVeerendra]

This might be the root of the problem: I tried running aapt2 directly from the terminal to test whether it starts, but it returns a segmentation fault. aapt at the least gives me the usages and subcommands. This aapt2 error doesn't happen in my old Intel laptop either.

[cmacfarl]

Replaces Intel silicon Mac with Apple silicon Mac. 3rd party application no longer works.

https://support.apple.com/en-eg/102527#:~:text=Rosetta%20works%20automatically%20in%20the,it%20like%20you%20normally%20would

Thanks @penguinencounter for the pointer.

[dmssargent]

Diving a bit deeper into this, since you should have the arm64 version that doesn't need Rosetta installed? The Mac targets should have that.

At a high level, this is more advanced, but it should rule out more possibilities. We're checking if your shell is configured correctly and if you have the right copy of aapt2 being downloaded. We're checking if we can get more information from attaching lldb to aapt2 to get the diagnostic information for what happened.

# Check we have the right file architectures
file ~/Library/Android/sdk/build-tools/34.0.0/aapt2
# .../aapt2: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
# .../aapt2 (for architecture x86_64):	Mach-O 64-bit executable x86_64
# .../aapt2 (for architecture arm64):	Mach-O 64-bit executable arm64

# Check our shell architecture
arch
# arm64

# Which shell are we using
which zsh
# /bin/zsh

# What architectures does it support?
file $(which zsh)
# /bin/zsh: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
# /bin/zsh (for architecture x86_64):	Mach-O 64-bit executable x86_64
# /bin/zsh (for architecture arm64e):	Mach-O 64-bit executable arm64e

If your shell is not arm64, you need to find a shell that is arm64. You can possibly try bash. zsh should be arm64, but that's another thing.

If that looks right, you can get more info about the crash? (lldb might require Xcode, use xcode-select to install)

echo run | lldb ~/Library/Android/sdk/build-tools/34.0.0/aapt2
# The attach might fail, but look for a segmentation fault, if so that points towards Rosetta being broken

If the aapt2 file information is wrong, can you try this direct link, unzip it, and find aapt2 inside and retest? https://dl.google.com/android/repository/build-tools_r34-macosx.zip. If that's correct, you're SDK needs to be blown away and reset, since your SDK Manager is providing the wrong configuration information.

[AddyVeerendra]

The shell configuration looks right to me. I tried using the echo run method, but it always returned an lldb - argdumper error. I used some other lldb commands, and had this returned.

(base) Addy-V@Mac ~ % lldb
(lldb) target create ~/Library/Android/sdk/build-tools/34.0.0/aapt2
Current executable set to '/Users/Addy-V/Library/Android/sdk/build-tools/34.0.0/aapt2' (arm64).
(lldb) settings set -- target.run-args "process" "launch"
(lldb) process launch
Process 63598 launched: '/Users/Addy-V/Library/Android/sdk/build-tools/34.0.0/aapt2' (arm64)
Process 63598 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000000000000
error: memory read failed for 0x0
Target 0: (aapt2) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000000000000
    frame #1: 0x00000001002e6984 aapt2`___lldb_unnamed_symbol13040 + 52
    frame #2: 0x00000001002e64ec aapt2`std::__1::ios_base::Init::Init() + 152
    frame #3: 0x00000001002e7794 aapt2`___lldb_unnamed_symbol13061 + 28
    frame #4: 0x000000018d7f3e90 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 592
    frame #5: 0x000000018d83229c dyld`invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 172
    frame #6: 0x000000018d825c38 dyld`invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 496
    frame #7: 0x000000018d7d82dc dyld`dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 300
    frame #8: 0x000000018d824bcc dyld`dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 192
    frame #9: 0x000000018d8275a0 dyld`dyld3::MachOFile::forEachInitializerPointerSection(Diagnostics&, void (unsigned int, unsigned int, bool&) block_pointer) const + 160
    frame #10: 0x000000018d831f90 dyld`dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 432
    frame #11: 0x000000018d7f3bb4 dyld`dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 176
    frame #12: 0x000000018d7fb190 dyld`dyld4::JustInTimeLoader::runInitializers(dyld4::RuntimeState&) const + 36
    frame #13: 0x000000018d7f4270 dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&, dyld3::Array<dyld4::Loader const*>&) const + 312
    frame #14: 0x000000018d7f8560 dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const::$_0::operator()() const + 180
    frame #15: 0x000000018d7f4460 dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 412
    frame #16: 0x000000018d813a0c dyld`dyld4::APIs::runAllInitializersForMain() + 424
    frame #17: 0x000000018d7dd8c8 dyld`dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3268
    frame #18: 0x000000018d7dcbc0 dyld`dyld4::start(dyld4::KernelArgs*, void*, void*)::$_0::operator()() const + 544
    frame #19: 0x000000018d7dc05c dyld`start + 2304

Just seems to confirm this is a memory access error. This also happens with the android-14 folder from the build-tools_r34 link above.

[AddyVeerendra]

I might have hit something, but I need some confirmation:

I used the "arch" command to change the architecture runtime. When using arm64, as before, the segmentation error occurs:

(base) Addy-V@Mac ~ % arch -arm64 ~/Library/Android/sdk/build-tools/34.0.0/aapt2
zsh: segmentation fault  arch -arm64 ~/Library/Android/sdk/build-tools/34.0.0/aapt2

I also tried it with the x86_64 architecture, but this time aapt2 seems to start up:

(base) Addy-V@Mac ~ % arch -x86_64 ~/Library/Android/sdk/build-tools/34.0.0/aapt2
error: no subcommand specified.
aapt2 [subcommand] [options] files...

Subcommands:
 compile                                           Compiles resources to be linked into an apk.
 link                                              Links resources into an apk.
 dump                                              
 diff                                              Prints the differences in resources of two apks.
 optimize                                          Preforms resource optimizations on an apk.
 convert                                           Converts an apk between binary and proto formats.
 version                                           Prints the version of aapt.
 apkinfo                                           Dump information about an APK in binary proto format.
 daemon                                            Runs aapt in daemon mode. Each subsequent line is a single parameter to the
                                                   command. The end of an invocation is signaled by providing an empty line.

Options:
 -h                                                Displays this help menu

the issue seems to stem from using the ARM version of aapt2, as the x86 version works fine. Is the reasoning here correct?