Since Android/IL2CPP support is experimental now, the generated binary is not being stripped of symbols, so it is pretty large. You can export the project, and use the stripper from NDK manually. That stripping tool should be in this location on Windows.
Android/IL2CPP is still planned to be experimental in 5.4. The current information from the Android team is that it will be fully supported “when it is ready” so we don’t have a release in mind yet. It should appear on the public roadmap when we know though.
Hello, I 'm trying to strip libil2cpp.so applying the command “arm-linux-androideabi-strip libil2cpp.so” and it reduces file size , but when I re-imported to the .apk file and run the application, the installation fails.
I wonder if it’s the right thing to do to reduce the size of apk
The device is a “Huawei Y330 (hwY330-U05)”. The compiled application without stripped works well (with unnecessary size), but when compiled in Android Studio, this stops working when the application starts
Ok, second try Why really would like to release our update tomorrow with IL2CPP generated code but we won’t release a IL2CPP with this increase in filesize.
I’ve attached a screenshot with our build settings. These are the same for the Mono scripting backend.
IL2CPP often has a larger footprint, but gives a performance benefit at the cost of size. IMO this is a valuable trade off.
You’re building a ‘fat’ binary that contains both arm7 and x86 code. You can remove the x86 target and decrease the size.
Also note, you’re worried about a 12mb total increase in size. What is your reasoning for concern here? 68mb vs 80mb in my opinion is not significant enough to be concerned. I don’t believe any user would be concerned about 12mb on any device that can run a Unity 5 app.
We have bad experience with increased filesize as people complained when we updated from Unity 4.x to Unity 5.2.2 and the filesize increased by, I don’t know, 10mb. Now we’ve updated to Unity 5.4.1f1 und the app already increased by 3mb. Plus 12mb when compiling with IL2CPP is not cool.
I believe on Android when you compile for mono it produce a dll with commond intermediate language, so the same dll is used for x86 and arm.
When you compile with IL2CPP the same code is compiled first for arm then for x86, creating two executables specific for each architecture.
So with mono you are essentially deploying your code in another form which get interpreted on the fly, so you could target 100 architectures and it would still weight the same( if you don’t account for the interpreter size).
And that’s the reason people says Unity games without IL2CPP can be easily decompiled and they are practically an open book.
The increase in size cannot be avoided unless you make an apk for each platform.
As I noted earlier, “You’re building a ‘fat’ binary that contains both arm7 and x86 code. You can remove the x86 target and decrease the size.”
So you can expect some increased size here.
You also say “Plus 12mb when compiling with IL2CPP is not cool.” - but you have not identified any actual ‘problem’ from this.
Being ‘cool’ or not is irrelevant. Compiling with IL2CPP gives faster performance and natural code obfuscation. I’d consider these to be FAR more cool than the lack of coolness of an increase of 12mb.
You’re not going to get the benefits of IL2CPP for free. There’s a cost associated with its use and that can include an increase in executable size (especially when you’re creating a FAT binary with both x86 and arm).
Do two builds, one for x86 and one for arm and deploy both versions through the Play Store (it supports such features).
I seriously think you mis-allocating your effort here, you’re worried about something that isn’t a problem (IMO) - unless you can explain what the problem is.