Add support for Raspberry Pi

[googoogagalala]

briefcase create fails >
Unable to download https://briefcase-support.org/python?platform=linux&version=3.7&arch=armv7l; is the URL correct?
followed tutorial exactly >https://docs.beeware.org/en/latest/tutorial/tutorial-3.html
Environment:**

• Rpi OS:
• python 3.5:
• Software versions:
  • Briefcase:
  • Toga:

[freakboy3742]

Thanks for the report! Transferring this issue to Briefcase, as that is where the underlying problem lies.

This isn't strictly a bug; we don't currently support Raspberry Pi OS (which is something we could fix - we just need time to do so).

There will be at least 2 changes required to Briefcase:

• Uploading Linux support packages compiled for Linux.
• Modifying the AppImage build command retrieve a RPi version of linuxdeploy.

The problem, however, is that there isn't currently a RPi version of linuxdeploy.

It may also be worth adding a note to the BeeWare tutorial to highlight that we don't support Raspberry Pi at this time.

[freakboy3742]

The Flatpak backend (added in #802; will be in the 0.3.9 release) might be able to support Raspberry Pi out of the box.

[rmartin16]

I built the helloworld app as a Flatpak on Raspberry Pi 4 running Raspberry Pi OS (Bullseye) for aarch64. That Pi doesn't have a GUI environment but everything went as planned.

[rmartin16]

As well as Flatpak, I've confirmed that building and running a deb package on a Pi 4b aarch64 works. I don't have a Pi with only 32bit support such as armv7l but such Pis should be supported as well now. Since #1132, 32 bit versions of Python are available to Briefcase. The last piece is arm support for linuxdeploy; there's been work on and off for linuxdeploy to publish a version with arm support but this is still outstanding.

[rmartin16]

As for building and running Android apps on a raspberry pi, it seems technically doable....but probably not out of the box.

The first issue is Java....since Briefcase only downloads the x64 version of JDK 8. The update to JDK 17 in #1271 will add support to download a JDK for other arches including aarch64.

The next issue is Android SDK manager can't find the emulator package.

$ briefcase build android -v

[helloworld] Updating app metadata...
Setting main module... done

[helloworld] Building Android APK...
Downloading the Android emulator...

>>> Running Command:
>>>     /home/russell/.cache/briefcase/tools/android_sdk/cmdline-tools/latest/bin/sdkmanager platform-tools emulator
>>> Working Directory:
>>>     /home/russell/tmp/beeware/helloworld
>>> Environment Overrides:
>>>     ANDROID_SDK_ROOT=/home/russell/.cache/briefcase/tools/android_sdk
>>>     JAVA_HOME=/home/russell/.cache/briefcase/tools/java17
Warning: Failed to find package 'emulator'                                      
>>> Return code: 1                      ] 10% Computing updates...              
Building...

I tried following Google's directions to run the emulator on arm64....but it requires more disk space than my Pi has available right now.

[edit rmartin16]
I was able to build the emulator on my main machine for aarch64 and copy it in to Briefcase's android_sdk directory on the pi. I needed to fabricate a package.xml file for the emulator. The platform tools that are installed by default are for x86-64, so I replaced them with these. Gradle attempts to use an x86-64 version of aapt2 but you can override this with the android.aapt2FromMavenOverride setting in gradle.properties....just use the version of aapt2 from the previously downloaded tools from lzhiyong. The build finally succeeded.

None of this really seems ideal...obviously. So, unless the Android command line tools are updated to stop assuming everything is x86-64, a lot of manual work or a different approach to layout the Android tools entirely would be necessary to build Android apps on raspberry pi

[freakboy3742]

FWIW: I'm entirely comfortable saying we don't support Android builds on RPi.

If Google doesn't provide an Android toolchain for Raspberry Pi, I don't think we should go to extraordinary lengths to support it. If we can catch the error/runtime state so that RPi users at least get a useful error message saying "please take up your complaint with Google", that's worth doing - but supporting "off label" usage of the Android toolchain is asking for trouble, IMHO.

The same goes for Linuxdeploy - they support one specific platform, so that's the platform we support with Linuxdeploy. Again, we can catch the edge case/error and report the limitation, but it's not on us to make Linuxdeploy work on ARM64.

It isn't our responsibility to make every tool work on every platform. It's not even our responsibility to fix problems with tools on specific platforms. We can report bugs and try to contribute fixes upstream if it's not too much of a distraction, but we drive the tools we're given. If those tools have bugs, we work around them as best we can - but at some point those tools need take responsibility for their own bugs and limitations.

That said - the general FLOSS contribution caveat applies: If getting Android/Linuxdeploy tooling working on RPi/ARM64 is your jam, by all means go ahead and contribute that support upstream. However, from BeeWare/Briefcase's perspective, it's not our problem until the tooling at least recognizes some form of support in an official capacity.

[rmartin16]

FWIW: I'm entirely comfortable saying we don't support Android builds on RPi.

Yeah...I was mostly curious about what all is missing. That said, it does seem that if someone sets up a working install of the Android SDK on arm64 (possibly for a bunch of RPis for a classroom or something) and specifies its path in ANDROID_SDK_ROOT, I'd expect things to mostly work.

I did find it curious that Google doesn't provide these tools already compiled for Linux on arm64. It seems they first made the code compatible with arm64....but mostly just so they could reach compatibility with Apple Silicon. I guess they just don't want to officially support binaries for Linux on arm64 given they are all dev tools...idk

Nonetheless, the spelunking was interesting :)

If we can catch the error/runtime state so that RPi users at least get a useful error message saying "please take up your complaint with Google", that's worth doing

I've been thinking about this more generally. Currently, we've implemented a check that a user's OS is at least the one that's expected. However, we aren't verifying much else beyond that. I think adding a system architecture check makes sense given we know many of the tools are not going to work on anything but x86 supporting 64bit addressing.

[freakboy3742]

I did find it curious that Google doesn't provide these tools already compiled for Linux on arm64. It seems they first made the code compatible with arm64....but mostly just so they could reach compatibility with Apple Silicon. I guess they just don't want to officially support binaries for Linux on arm64 given they are all dev tools...idk

If I had to guess, it's all about support. Raspberry Pi is (mostly) a hobbyist platform; there's not a whole lot of evidence to suggest it's being used by mainstream app developers. Supporting an entirely new hardware platform takes resources; if I were in Google's shoes, deciding to ignore ARM64 Linux for Android development would be a no-brainer. Supporting Linux at all would be on the borderline.

I've been thinking about this more generally. Currently, we've implemented a check that a user's OS is at least the one that's expected. However, we aren't verifying much else beyond that. I think adding a system architecture check makes sense given we know many of the tools are not going to work on anything but x86 supporting 64bit addressing.

Definitely won't get any argument from me that this would be worthwhile. Windows has an analogous set of issues - ARM64 devices aren't common, but they're also not unheard of - my daughter has one for school, and the last time I did an in-person tutorial session, there was one student who turned up with a Windows surface.

[rmartin16]

FWIW: I'm entirely comfortable saying we don't support Android builds on RPi.

Yeah...I was mostly curious about what all is missing. That said, it does seem that if someone sets up a working install of the Android SDK on arm64 (possibly for a bunch of RPis for a classroom or something) and specifies its path in ANDROID_SDK_ROOT, I'd expect things to mostly work.

To close this loop...if one manages to get a working Android emulator on aarch64, Briefcase will error on downloading a system image for it since this is currently limited to x86-64 and Apple Silicon. Using the arm64-v8a system image to create an AVD, though, finally allows Briefcase to build and run an APK.