As I want to reduce my app size. So I got below suggestion from Appcelerator forum
You can reduce this size depending on which Android API levels you
target.If you need to reduce size, You have to create two separate
apks for older (armeabi) and newer (armeabi-v7a) devices
So I want to remove for older (armabi). As Targeting an ABI architecture will help reduce the application and APK size
How to define target ABI property in tiapp.xml in Appcelerator?
While surfing on google I got below tag:
<property name="ti.android.abi">all</property> <!-- to support all devices -->
<property name="ti.android.abi">armabi, armabi-v7a</property> <!-- to support both old, new devices -->
<property name="ti.android.abi">armabi</property> <!-- to support old devices -->
<property name="ti.android.abi">armabi, armabi-v7a</property> <!-- to support new devices -->
After each of above trial I didn't got any change in memory size of apk file.
Note: I am building this app for android device
Can anyone help on it ?
I don't have first-hand experience with it, but the documentation suggests that it's not a property of ti.android.abi, but instead, it's an element inside the android-specific section of your tiapp.xml.
For example:
<android xmlns:android="http://schemas.android.com/apk/res/android">
<abi>armabi</abi>
</android>
Note that you should understand the ramifications of not including support for all ABIs. It's more than just reducing your app size. Eliminating armabi-v7a could reduce performance for newer devices, and eliminating armabi means older devices can't run your app at all.
Related
I noticed that on release configuration an Uno blank app is about 22mb for android. Can it be reduced ..?
I also noticed that a blank xamarin forms app is only 14 mb. (Both for per abi apk)
You can enable Application App bundles (.aab). It will reduce your application size even more once deployed through the Google Play store.
To enable it, look in your *.Droid.csproj properties
This xamarin blog post is a good reference.
There are a few things you can do to reduce the app size.
Enable Android App Bundle (.aab)
If you currently use the .apk format for your Android package, you can reduce your app size by switching to .aab format.
Here is a guide on how to enable it.
Enable Profiled-AOT
If you currently use full AOT, you can reduce the app size by enabling Profiled-AOT.
Here is a guide on how to enable it.
Remove unused assets
Make sure you remove any asset that you don't actually use in your app. That includes images, fonts, sounds, videos, etc.
Remove unused package references
Make sure you remove nuget references that you don't actually use.
I have a Xamarin Forms app that is currently on the App Store that I built and submitted in October 2016 (with what I assume was the latest versions of Xamarin Studio and Xamarin.iOS back then). The app has a size of 50 mb on the App Store.
After doing a few updates to the app, I build it now (AppStore config, then Archive) and the size is 82 mb. Confused by this balloon in size, I switched back to the git tag of the version that is currently in the App Store. I can build the same exact tag/version/code for that October 2016 release and it's App Store size is now 80 mb.
I am using the latest Xamarin Studio (6.3 build 863), Xamarin.iOS (10.8.0.175), etc.
Why has the size grown by 60%? No application code or libraries have changed, only newer versions of Xamarin Studio and Xamarin.iOS. How do I figure out what is going on here? I can do an Add-Hoc build on my device and see that is only taking up ~55 mb, very close to what I see from the App Store.
Also, note that I am not comparing the .ipa size. I am comparing the "Estimated App Store Size" shown from the archive screen in Xamarin Studio after archiving a build. The same size difference is reflected after submitting the signed build via application loader to iTunes Connect and verifying from iTunes Connect > Activity > All Builds > App Store File Sizes.
Update Sept 5th 2017
Not sure what changed but now with the latest version of Xamarin iOS, Version: 10.12.0.20 (just updated), my app size is now back down in the 60mb range... Didn't change anything else.
I can do an Add-Hoc build on my device and see that is only taking up ~55 mb,
You likely have some different options between your configuration, e.g.
managed linker settings, e.g. Don't link versus Link SDK;
targeted architectures, e.g. armv7+arm64 versus armv7+armv7s+arm64;
How do I figure out what is going on here?
Compare your build logs, in particular the options given to the mtouch tool. That will generally pinpoint the difference quickly.
I am comparing the "Estimated App Store Size"
Always compare the IPA (file) size. The algorithm to guess the final size is known to be often (very) wrong. The estimation also comes from Apple's tools so they will vary with the version of Xcode you're using (which is unlikely to be identical to the one you used last fall).
Side note: the final size is even trickier to guess when bitcode is enabled (which is only for tvOS and watchOS builds right now).
My guess is that xamarin is packing a lot of unneeded stuff, maybe old images or similar that you are no longer using. I have experienced that myself.
Go to you project folder and delete everything in the obj folder
<myproject>/iOS/obj/
Usually you will see two folders in there: iPhone and iPhoneSimulator.
Delete those and build everything again, there's a good chance that will solve it
Are you using the same version of Xamarin to build your code. I am willing to bet that is the issue. Something changed in how Xamarin builds apps since the last time you released it and is blowing up your app build size.
If you actually have the same code you released back then do you know what version of Xamarin you used back then? Honestly since the only thing that's changed is the Xamarin compiler it is most definitely the issue.
There are four things to do:
DELETE bin and obj folder from client project
CHANGE architecture to only support 64
CONFIGURE the linker.
Best is to try and build your app with linker active, but the more nuget packages you use, the less likely this is
and most importantly:
Set your build config to RELEASE and not DEBUG
(if you forget that, stores will accept your app but size can easily be doubled or even trippled)
This is how the minimal setup should look like:
Then dont forget that XAMARIN adds libraries like crazy to your app. I once read that the smallest app with NO content at all is at least 7 MB. This only gets larger with each package and each new dependency.
Currently our Xamarin Android app (PCL) is huge in my opinion, even in release mode. I suspect it is due to supported architectures. Currently we have them all selected. Does anyone know if we have to select all of these? We are not using the Android NDK at all as well.
I will copy part of my answer from here.
Make sure you are at least checking the following architectures: armeabi-v7a and x86. You could do the other three but we do not since we use LLVM compiling in release mode, which is not compatible with the 64 bit architectures (except for armeabi, which is deprecated). The good thing about that is that all of the 64 bit architectures can still use 32 bit builds so they all still get covered if you check those 3.
So I would just check those 3 unless you have a specific reason to check the other ones. We have had 0 problems installing our app on devices using those 3 only.
On a side note, turning on LLVM compiling and optimizing your icons/images will help with the final APK size.
*Edit: Since writing this we ran into a bug only on certain devices (Android Nexus 9) which leads to app crashes when launching the app. The solution is to check the arm64-v8a architecture. This will probably increase app size so weigh the pros and cons and see how much of a difference it makes in your APK size after including the architecture or split your APK for each architecture if necessary.
No you do not have to select all of them. You can create an .apk per ABI if you wanted to to reduce the size of your .apk. Note: The encouraged method is that you develop and publish a single .apk. However this is not always practical, and sometimes it's better to create separate ones. Although this answer only goes into depth about different CPU Architectures (ABI), you could also create different .apk for screen size, device features, and API levels.
https://developer.xamarin.com/guides/android/advanced_topics/build-abi-specific-apks/
http://developer.android.com/google/play/publishing/multiple-apks.html
I would recommend grabbing a tool like WinDirStat(https://windirstat.info/) or Disk Inventory X(http://www.derlien.com/) to investigate why your .apk is so large. You might find other reasons why your .apk is large such as resources(images, raw files), assemblies, etc.
Is it possible to create an AltBeacon (so start advertising) on Android with the official Android AltBeacon library?
https://github.com/AltBeacon/android-beacon-library
Much like we can create an AltBeacon using the iOS libray and start advertising (https://github.com/CharruaLab/AltBeacon) can advertising be achieved on Android 4.3+ ?
Yes, you can use the Android Beacon Library to transmit, but it requires Android L and is not possible with Android 4.3. See the sample transmitter app here:
https://github.com/AltBeacon/altbeacon-transmitter-android
This sample app is based on a branch of the library that targets the new Android L operating system and provides a BeaconTransmitter class. Once Android L is released, this branch will be merged into the official release of the library.
The reason transmitting requires Android L is because Android 4.3 does not support BLE Peripheral mode needed to transmit as a beacon.
It is also important to note that the iOS AltBeacon project from CharruaLabs Lab mentioned above is completely independent and uses a different incompatible transmission format.
My basic question is : Will developing android apps with android 2.2 SDK work for android tablets running on Honeycomb (android 3.0) and higher versions ?
Also, will apps developed for phones work on tablets ?
Adithya.
Yes, you can have the same apk work with 2.x and 3.x. Just use something like this in your manifest xml:
<uses-sdk android:minSdkVersion="4"
android:targetSdkVersion="11" />
If you have created a virtual android tablet you can test it on a tablet emulator, just right click your eclipse project, Run as -> Run Configurations, then check android 3.0+ in target tab.
For more info see:
http://developer.android.com/guide/practices/optimizing-for-3.0.html#Optimizing
As to the first they should, it's supposed to be forward compatible.
Having said that depending on how you developed you app it's possible that you are making use of features not present on the tablet. I have had apps that work on phones tank when I tried them on the tablet, mostly because I was not checking feature sets properly (mostly in the camera) so you do have to take some care.
Really this is not a tablet issue, more of a supported hardware issue but it becomes pretty apparent on those, many don't have cameras for instance, some don't have GPS etc.
As to the second, yes, but they won't be optimized for the tablet so your users might not like tiny images if you have not provided for higher resolution screens
I think no. Devices with Android 3.0 ang higher have xLargeScreen resolutions. And Android 2.2 doesn't have support for this. Only Android 2.3+