We have a near complete application, and are trying to squeeze under the 50MB download limit for Google Play.
When inspecting our APK to try to find ways to drop our file size, I noticed the lib\x86, lib\armeabi, and lib\armeabi-v7a directories that are described here. They correspond to the 'Supported architecture' option in project options of a Mono for Android project.
If I remove x86, I save around 1.1 MB on our APK size. (This is almost enough to get us under 50MB)
What are the drawbacks for removing x86?
Will my APK still run on x86 devices?
Is there any substantial market share on Google Play for x86 devices?
If it will not work on x86, will Google Play prevent my APK from being installed on x86 devices?
Note that the following answers are for general Android development and do not reflect anything specific to Mono:
What are the drawbacks for removing x86?
Your app will not run on x86 devices. Intel may cry.
Will my APK still run on x86 devices?
No.
Is there any substantial market share on Google Play for x86 devices?
IMHO, not presently. A few handsets were released in 2012 that are Intel-powered (e.g., Motorola RAZR i), and the first generation of Google TV devices were powered by Intel CPUs. But Google TV has switched to ARM, and it will be some time before Intel CPUs make up a substantial portion of the Android device ecosystem (again IMHO).
If it will not work on x86, will Google Play prevent my APK from being installed on x86 devices?
It should. If not, the Play Store has serious issues. While I have a RAZR i sitting here, I don't off the top of my head know an app that uses native code that does not ship with x86, to see if the app in question is indeed filtered out of the Play Store.
are trying to squeeze under the 50MB download limit for Google Play
If a 1.1MB savings "is almost enough to get [you] under 50MB", you are already in trouble. Apps tend to grow, not shrink, over time. If you expect that you will be able to switch to some other distribution architecture (e.g., use APK expansion files) eventually and just need a short-term stop-gap solution, cutting x86 may be OK. But you really need to have a plan for dealing with app size growth that takes you back over the 50MB barrier, and you may be better served addressing that now rather than shipping something and finding yourself painted into a corner as a result.
Related
I am trying to make an Android app in Unity that uses some heavy computation, when I tried to publish it to the google developer console I got an error "This release is not compliant with the Google Play 64-bit requirement"
After some digging around I found that I need to change the Scripting Backend to IL2CPP Instead of Mono and un-select x86
Now Google lets me publish the app, but when I build and run it on my phone it is significantly slower, should I be worried about this? If so is there any way to fix this? (when I change Scripting Backend back to Mono and build and run the app doesn't lag any more when it's running, perhaps there are some different settings that I need to use?)
What I read so far was that the Scripting Backend IL2CPP is supposed to be faster as far as when the app is run, but at least on my phone this doesn't seem to be the case
The phone I'm using to test this is a ZTE Blade, Model number Z965 (I think it's called ZTE Blade X but I'm not sure)in case that's useful
I (might have) found the reason for the lag from this post:
https://forum.unity.com/threads/huge-fps-drops-from-60fps-armv7-to-25-30-fps-arm64-unity-2017-4-20.682018/
It seems that any logging operations take a long time using the ARM64 architecture(I ran the app using the ARMv7 and ARM64 architecture and the ARMv7 didn't lag that much) now that I changed every logging setting to "none" the app seems to run more smoothly(anyway at least I hope that was the only problem)
I am having a problem with my unity build when targeting the Universal Windows Platform. The game runs perfectly (200+ FPS) on the regular x64 Windows build, but as soon as I run the build through the App packages or Visual Studio for UWP, I get only around 30 FPS with studders as well.
At first I thought it was a VSYNC issues, but the studdering makes me think otherwise, as well as the setting not being set in the graphics settings.
When I run the build on Xbox One with the app package, the system performance is the same as on PC, 30 FPS and some studdering. The system profiler on the Xbox One is saying that File I/O is causing some problems, so possiblly garbage collection?
As far as garbage collection goes, the worst thing that I would be doing is setting game objects as inactive/active through an object pool.
Any clues as to why the performance is so bad only on one platform? Or optimization tips for UWP specific?
I'm using MSVS2015Pro with C#/Xamarin.
I have a laptop that doesn't support Hardware Acceleration.
Then I have a question: can I develop for mobiles without having to spend too much time when deploying?.
I could deploy to my real android phone, but I don't know if that's slower than deploying to an AVD. Is it?
What Can I do? I don't wanna do things in a very slow manner.
Do I have to buy a another laptop that supports Hardware Acceleration?
If that's the case, what other requirements I need for that other laptop?
We are running windows 10 with VS 2015 Pro and no hardware acceleration available on the CPU. There is indeed a solid state drive and 16gig ram (The ram doesn’t really assist in running the emulator though. More ram doesn't make the emulator faster. It is rather the processor and or GPU. The ram does assist with running multiple emulator instances.)
Doing both xamarin.iOS and xamarin.android development. I would agree that with hardware acceleration things would be much faster but it is possible to dev on an enterprise level without it. The deployment to emulator (once emulator has started up and is running) vs actual device is much the same. It is indeed faster running the app on an actual device.
I would suggest using actual device to test functionality and the user experience of the app for quick feedback cycles while using the emulator to test different OS versions for compatibility.
I am using a remote desktop having configured Win 8.1, 3gb ram DDR2, 15gb HDD free space, latest Xamarin Studio Starter version with api 21 packages. When I try to debug a simple "Hello World" solution on studio, the manually created AVD loads too slow, even android home screen does not appear after 1 hour. What should I do to speed up the process ?
I don't know if your IDE supports it but you should really try out Genymotion, it changed my development time and testing significantly.
https://www.genymotion.com/
Considering your configuration, 1 hour is too much, try restarting first.
If not go for your Android device(physical), I debug on my mobile(you don't have to wait for your mobile to start).
You Can also go for Genymotion . Many find difficulty in genymotion setup. it is pretty simple though, follow this video If you'll understand once about VirtualBox and IP, it'll be easy for next time
I would recommend 6GB Ram and i5 processor for performance lag problem. So if it is possible, you should upgrade your machine.
Thanks for your responses. Finally I have resolved the issue by creating a low resolution Android Virtual Device (Nexus One) by Xamarin Studio.
But another problem arises, the published apk file is too large.Which steps need to be done to make it perfect ?
You should try the Xamarin Android Player. In my experience it's the fastest option over Genymotion and Android's AVD images even with Intel's HAXM installed.
https://www.xamarin.com/android-player
Nowadays a good deal of laptops come with 2 GPUs - a high-performance one and a power-saving one (less powerful). Most of the application, which I use on my laptop run with my integrated(power-saving) GPU, but still some of them are set to open with the high-performance card. I am trying to config the app which I am building to run on the high performance GPU by default, but I can't find any information about the topic anywhere. I hope that someone can shed a bit of light onto this. I will distribute my application with an NSIS installer and I guess that I'll have to add the path of my application to a list of applications for NVidia/ATI cards. The application is programmed in C#. Also, does anyone know how things stand with desktop PCs? What happens if a PC has 2 GPUs and I have to choose the more powerful one?
Milcho