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.
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 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.
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."
I have a Unity project that I'm switching from APKs to AABs (app bundles). Previously, when I was building it as an APK, the Google Play Console told me the APK was 64-bit compliant.
Now that I'm building an aab, I'm getting the warning:
This release is not compliant with the Google Play 64-bit requirement.
The following APKs or App Bundles are available to 64-bit devices, but
they only have 32-bit native code
I have both ARM7 and ARM64 architectures set.
I am excluding x86.
When I open the .aab in an archive viewer, the lib folder has all of
the .so's for both arm64-v8a and armabi-v7a.
I'm using IL2CPP, .NET 4.x
I'm using Unity 2018.3.7f1
My ndk version is 16b
My
Android Studio is up to 3.4.2 and gradle is 3.2
A lot of similar threads here talk about following the "Learn more" links, which I've done. I had already done all of the work to get my app 64-bit compliant before switching to app bundles.
Other threads talk about Android Studio solutions, which I can't use because my automated build process involves building with Unity from command line, so it has to be Unity configurations or bust.
My expectation was the app bundles were supposed to be the hot new way to let Google build better APKs for you, but it seems like it's getting confused on whether or not aabs are actually 64-bit compliant, which seems to defeat the whole purpose.
Is this a Unity problem, does Google have an error in their system with regards to app bundles, or is there some other step I'm missing?
For those who have this problem since yesterday (August 19, 2019):
In Player Settings > Other Settings you must now uncheck the x86 box (It is for the 32-bit Intel architecture).
You will now only have the following warning:
The device types on which your application can be installed will be more restricted.
But, in my case, it drops from 12392 devices to 12385 devices.
Here is the opinion of a Unity member on the issue:
x86 is used by less than 0.4% of all Android devices, so it shouldn't have any real impact.
x86 target will be removed completely in Unity 2019.3.
It looks that there was a bug in the Play Console where this message was displayed even when the AAB was compliant. This should have been fixed last Friday afternoon.
Try again now.