Building the Flutter engine for embedded hardware

Mar 1, 2023

Pieter Scholtz

So you want to run flutter on an embedded device? I would not be surprised if you have run into the issue of not being able to find a fitting flutter engine build. No worries you came to the right place.

I am going to make an assumption that most embedded hardware will most likely be either ARM or ARM64 hardware running Linux. If you are doing something different, please do reach out in the comment section.

First one needs to setup the engine development environment. The flutter development wiki does do a pretty good job of this and can be found here , a few tips from me :

create the engine directory in the same directory as a peer to your flutter SDK directory. This makes it easier for the flutter SDK to find locally built engine artifacts, more on that here
Use a Linux system to build these artifacts.

Next up you need to get to building/compiling the engine. Documentation can be found here.

Examples:

Building the flutter engine for a 32 bit ARM Linux device in debug mode

From the engine/src directory I would run this :

./flutter/tools/gn --no-goma --target-os linux --linux-cpu arm --arm-float-abi hard --embedder-for-target

and then:

ninja -C out/linux_debug_arm

After that has completed, you will find the build artifacts inside out/linux_debug_arm

among these files you will find the following:

libflutter_engine.so is your flutter engine library binary, it looks different on different platforms for example on Linux it will have a .so extension, but on Windows it is a .dll file

icudtl.dat is also important, and is required by embedder API It is important for font rendering.

Building the engine for a 64 bit ARM Linux device in profile mode

./flutter/tools/gn --no-goma --target-os linux --linux-cpu arm64 --runtime-mode profile --embedder-for-target

and then:

ninja -C out/linux_profile_arm64

You will notice that the artifacts look slightly different when building for profile or release mode.

gen_snapshot This is used by the flutter SDK for building flutter applications and not by the embedder.

Engine artifacts version mismatch

If you run into this error when trying to utilize your freshly built artifacts.

Dart Error: Can't load Kernel binary: Invalid kernel binary format
version.

It means that there is a mismatch between the version of engine artifacts you are using and the version of the flutter SDK you used to build the application you are attempting to run.

If you want to build a specific version of the flutter engine, you can change the version by running this command inside the engine directory.

gclient sync --revision=src/flutter@COMMIT_VERSION

You can check if it worked by running the following inside /engine/src/flutter

git log -n 1

Keep in mind that the Flutter SDK you are using indicates the commit version for the engine artifacts that is to be used with it. The engine.version file located at flutter/bin/internal holds the commit hash. Take care to not confuse this directory with the engine/src/flutter directory.

12 comments on "Building the Flutter engine for embedded hardware"

Victor Johns

Mar 9, 2024, 7:12 AM

Hello, I was wondering if you had the commit/version for the flutter engine that you used when doing the ARM(32 bit) build. Seems (??) like the latest flutter engine code does not build with the gn arguments provided. A possible approach to workaround this might be to use a gcc cross compiler instead of clang; I think would present it's own set of issues. Seems a shame that current flutter engine does not build for ARM32 platforms. Quite a few of our clients would prefer to use one of the cheaper ARM platforms ( for instance STM32MP157) instead of the more expensive 64 bit platforms Just thought I would check Best Victor

Pieter Scholtz

Apr 2, 2024, 11:43 AM

Hi Victor, Please have a look at https://github.com/ardera/flutter-ci , it builds the latest binaries for 32 bit arm. Pieter

Andrea Marson

May 4, 2024, 7:52 PM

Hello Pieter, I didn't understand how to cross-build an app for linux-arm target so that it works in tandem with the engine for ARM (no matter whether it is built following your instructions or it is prebuilt). The Flutter SDK does not support such a target: $ flutter build linux -h Build a Linux desktop application. ... --target-platform The target platform for which the app is compiled. [linux-arm64, linux-x64 (default)] Sorry for the naive question, but I am new to the Flutter world. BR, Andrea

Pieter Scholtz

May 28, 2024, 10:50 AM

Hi Andrea , yes the building process is not very obvious at first. I would strongly suggest using https://pub.dev/packages/flutterpi_tool to build the flutter applications , but if you want to know more about it you can have a look here : https://github.com/ardera/flutter-pi?tab=readme-ov-file#building-the-app-old-method-linux-or-windows (the debug build is JIT compiled , and runs anywhere , therefore no need to specify the target platform) Building for profile or release mode requires some attention to the target platform , there is the "old method" but it is a bit tedious : https://github.com/ardera/flutter-pi?tab=readme-ov-file#building-the-appso-for-running-your-app-in-releaseprofile-mode

H Satish Kumar

May 31, 2024, 1:48 AM

Hello, is there any way to built flutter app for 32 bit Linux i.e., x86 arch?

Hannes Winkler

Jun 6, 2024, 12:09 PM

Hey Satish, it's definitely possible, the Dart SDK supports 32-bit x86, but it's not really supported by the Flutter SDK / third party tooling because there's just no users for it. Also chances are, if you can get the flutter app built for x86 32-bit, you'll run into different problems because the overall platform is probably outdated as well (GPU, drivers). But if you do need it, feel free to open an issue here: https://github.com/ardera/flutter-ci

Sean Breslin

Sep 9, 2024, 5:02 PM

Hello Pieter, is this ARM64 build statically linked with libraries such as the c++ and glibc, if not can they be statically linked?

Hannes Winkler

Sep 11, 2024, 10:05 AM

Hey Sean, libc++ is statically linked. The engine builds its own specific version of LLVMs libc++ and statically links that on all platforms. glibc probably not, but AFAIK that's rarely done in general, what's your use-case?

Sean Breslin

Sep 19, 2024, 1:00 AM

Im trying to build flutter for an arm64 but my toolchain is to old so I made a new tc with crosstool-gn with newer c and GLIBC to build the flutter-engine and I was hoping that I didnt need to build my entire project with this new tc if flutter statically links glibc but I guess I cant get away with that. but then I realized I dont have any wayland libraries with the latest tc either so I guess I have to build everything to the new tc.

Krishna Kumar

Nov 11, 2024, 5:52 AM

Hi, The problem with arm32 seems to be that the default flutter sdk's that get installed (even if you have changed the config.txt on an RPi4 to get it to boot in arm32 mode, and for all practical purposes as far 'uname -m' etc. seem to reflect, you are in arm32 mode) are arm64 versions, even on an RPi4 running in arm32 mode. The arm32 engines are available from: https://github.com/ardera/flutter-ci, but the basic problem seems to be that the sdk's that you use to create the apps seem to be all arm64 ones, and obviously, the flutter engine code that gets executed when you try running the app (the arm64 binaries that you have created from the arm64 sdk) complains about 'architecture mismatch'. Are you aware of any solution that can force the download/install of an arm32 flutter sdk? Thanks a lot!

Pieter Scholtz

Nov 11, 2024, 8:34 AM

Hi Krishna, Are you running the sdk on the RPI itself ?

Krishna Kumar

Nov 13, 2024, 11:33 AM

Hi Pieter, thanks for your quick response. Yes, I was running the sdk on the RPi, have tried it from within a dockerized qemu for arm32 as well - when I debugged the problem the root cause seems to be this piece of code in a start-up script in the flutter git: https://github.com/flutter/flutter/blob/5fd650f68b9c644ebd122b2283d020e0bbb2a40e/bin/internal/update_dart_sdk.sh#L75 Line 95 is the root cause of the problem - it defaults to arm64 if not x86_64 and hence the dart sdk for arm64 is fetched even in qemu arm32 and RPi in arm32 mode. And, then you obviously, get a mismatch. Might need a fix to look for arm32 and not just default to arm64 when it isn't x86_64.