When I build a Windows version of a Flutter app it creates a
build\windows\runner\Release\data\app.so 6MB sized file.
Obviously it an Linux ELF library yet deleting or renaming the file makes the EXE fail to start.
What kind of sorcery is this?
As answered in Github:
"Flutter applications that are AOT compiled us a .so on Windows, Linux desktop, and Android. This file contains only your Dart code. Separately, the executable is compiled from the platform specific entry point in the windows directory, along with your plugins and this depends on a dll (flutter engine) which contains the actual engine as well as the support for loading AOT compiled Dart code."
Related
I want to build an application using flutter.
According to Flutter website:
Get native-compiled performance without large browser engine dependencies.
Are flutter app's compiled to machine code or byte code?
There are multiple ways to run Dart programs. Please refer to the dart compile documentation.
Quoting from referenced page, a few of the compilation options include:
exe: A standalone, architecture-specific executable file containing the source code compiled to machine code and a small Dart runtime.
aot-snapshot: An architecture-specific file containing the source code compiled to machine code, but no Dart runtime.
jit-snapshot: An architecture-specific file with an intermediate representation of all source code, plus an optimized representation of the source code that executed during a training run of the program. JIT-compiled code can have faster peak performance than AOT code if the training data is good.
Note: You don’t need to compile Dart programs before running them. Instead, you can use the dart run command, which uses the Dart VM’s JIT (just-in-time) compiler--a feature that’s especially useful during development.
A Windows desktop application written with Flutter would be compiled to machine code. Flutter is a mobile app development framework that uses the Dart programming language. It can be used to develop apps for both Android and iOS, as well as for desktop platforms such as Windows and MacOS, using the same codebase. When you build a Flutter app, it is compiled to machine code, which is then executed by the target device's processor.
I've build aosp_x86_64-eng target on Linux and now I can start it using emulator command. However, I'm looking for a way to "deploy" the .img files and whatever is necessary to Windows, so I could run the same emulator on Windows.
My main problem is that in out directory (out/target/product/generic_x86_64) there are a lot of things and I'm not sure which to choose and how to glue them with .ini and .prop files. I also didn't find any working tutorial or example on that topic. On the other hand I'm sure it's possible, since Google provides working emulators for Windows and they had to be build on Linux or Mac OS.
I saw this as part of the logs generated by Gradle when building an app in release mode in flutter. Does this have any side effects on the overall app?
libflutter.so is already the compiled form of flutter framework and other native scripts needed to run your app.
More specifically *.so files includes Dart language dependency, skia engine, flutter framework, platform related native code etc.
So their is no need to break them and compile them as they are already compiled. Hence it shows the message that cannot strip them packaging them as they are. This doesn't have any side effects. (*.so files are compiled form of code that are designed to run on linux distributions.) Android is also a linux distribution.
Hence there is no side effect on the app which you are building.
I read somewhere that Flutter compiles its code to ARM binaries. These ARM binaries can be understood by both ios and android and thats how flutter achieves cross-platform. If so where can we see ARM binaries? Are APK and ARM binary the same?
Can someone share some more details on it?
Here's an explanation about the comparison of dart's compiled binaries and android's apk. The page also has explanation about iOS platform compilation with Flutter. This paragraph also talks about how the Flutter VM is used, just in case you wanted to know about the JIT compiler. https://docs.flutter.dev/resources/faq#run-android
The engine’s C and C++ code are compiled with Android’s NDK. The Dart
code (both the SDK’s and yours) are ahead-of-time (AOT) compiled into
native, ARM, and x86 libraries. Those libraries are included in a
“runner” Android project, and the whole thing is built into an .apk.
When launched, the app loads the Flutter library. Any rendering,
input, or event handling, and so on, is delegated to the compiled
Flutter and app code. This is similar to the way many game engines
work.
During debug mode, Flutter uses a virtual machine (VM) to run its code
in order to enable stateful hot reload, a feature that lets you make
changes to your running code without recompilation. You’ll see a
“debug” banner in the top right-hand corner of your app when running
in this mode, to remind you that performance is not characteristic of
the finished release app.
Every time I do flutter build, I get a file change in
ios/Flutter/flutter_assets/kernel_blob.bin
After committing and rebuilding then I get a lot of conflicts because of this file.
What is this file? Should I .gitignore this?
The short answer is that this file is a Dart kernel bytecode representation of your app's code generated by a compiler in Flutter's toolchain. When your Dart code changes, you should expect the built kernel_blob.bin to also change.
In a bit more detail, the flutter tool is responsible for managing the build pipeline for your Flutter app. Since your example is an iOS example, I'll describe an iOS build. During a compile via flutter build, the tool does the following:
Compile source to Dart kernel bytecode: the flutter tool locates your app's main entry point (by default lib/main.dart) and hands it to the Dart kernel compiler. The kernel compiler traverses the import graph, and emits kernel bytecode to kernel_blob.bin.
Compile kernel to ARM assembly: In AOT builds (profile or release mode), the kernel bytecode is then handed to the gen_snapshot tool, which on iOS emits ARM assembly code (we do this twice, once for 32-bit and once for 64-bit).
Compile assembly to an iOS framework: The assembly code for each bitness is compiled into an iOS shared library (.dylib file) using the clang compiler. We then use lipo (part of Xcode's toolchain) to merge the two .dylibs into a universal binary and wrap it up as a framework, including verison info, Info.plist, etc. This is emitted as App.framework.
Generate the iOS .app bundle: The native bits of your app are compiled into an iOS .app bundle. Both App.framework (your app) and Flutter.framework (the Flutter engine/runtime) are bundled into the app's frameworks directory.
Install the app to the device: The .app file is installed to the connected device and optionally launched.
You should ignore this file (and the rest of the build directory) in your .gitignore.