Maximum application size of android & BADA platform - android

what is maximum size of thick/thin client application(to d/w through OTA) in both Android & Samsung Bada platform ?

yokks, you need to have a look # this thread Android - Application (apk) Maximum size for android

If you mean the Android Market by "OTA" which is the most common case since it handles update notifications, etc. - you should know that the apk size limit to upload on the android market is 25 MB. But other than that, I don't know of any limitation, it probably also depends on the device you're targeting.
If you implement your own OTA delivery technique, then of course you don't have this limitation.
Also you should know that on Android you can always/mostly break down one application into multiple smaller ones, if your app elements are very modular, in case you have issues with one single apk size.

Related

How to make sure that your application will be compatible with range of devices?

In Google play (app market), if an application is not compatible to your device (for some reason, say small screen size, etc). Then it is not even shown in the list.
Now, as an app developer I never want to unintentionally add a limitation in my app that forbids it from a range of devices.
So, while developing how can I make sure that the application will be able to run on atleast the type of devices that I intend.
Also, right now I'm developing an app & testing it in on my phone with version 2.3.5. And every now & then Google changes some method names & flags.
For newer android releases, I CAN test it on emulator, but testing it on phone/tabs/etc. is a different thing.
Please suggest.
how can I make sure that the application will be able to run on atleast the type of devices that I intend.
In manifest file you can mention, which type of device you want to run your app. And for testing you can create emulators for different devices to test your app. Try to make app UI such that it runs on all devices.
Google changes some method names & flags
Whenever Android changes any thing it will always be upward compatible means if you have made app for 2.2 it will run on 2.2 and above (screen size or resolution is other thing)
Regarding UI see my answer here
Layout for 720*1280 devices
By default apps will be available to as wide a range of users as possible.
There are certain limitations you can define in your manifest file, such as not being available on small screen sizes, but they are at your discretion.
The only limitation Google imposes on you is that any user who has a lower Android version than your minimum SDK version cannot see your app. To get around this, you can either design the app for lower SDK versions (I believe building for 2.2 and up gives you access to about 95% of the user base) or maintain multiple versions of the APK.
Read this. It will really help. Next Eclipse will help you a lot, firstly you can define what you wish to support (screen sizes and hardware requirements or even if they're not necessary but may be used) in the manifest. You can run a version check and implement APIs dependent on which version of Android you're running on. That's personally what I do, I check the API level and if it's greater than or equal to the API I wish to run I run it, otherwise I attempt to find compatible code (often using the compatibility library) or alternatively drop support for that feature, for example JellyBean notifications there's not really any work around for expanded notifications but I can use the NotifcationCompat builder.

Complicated interface logic switching between handset and tablet versions - publish 2 apps?

Is it possible to publish an app that will target only handsets or tablets and simultaneosly show itself appropriately in GooglePlay store ?
The thing is that logic that switches functionality between handset and tablet versions starts to be a bit complicated and messed up. For instance, in handset version ViewPager is used while in tablet - TabHost. This forces to apply if-statements and I've only started and don't think that it will look better if I continue.
This logic switching is all about the interface - backbone data operations remain intact on both versions.
What's your experience on this issue and should I consider writing two separate apps ?
Thanks.
http://developer.android.com/guide/google/play/publishing/multiple-apks.html
Develop app for handset and tablet separately with same pkg name.
All APKs you publish for the same application must have the same package name and be signed with the same certificate key.
Each APK must have a different version code, specified by the android:versionCode attribute.
Each APK must not exactly match the configuration support of another APK.
That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).
Usually, you will differentiate your APKs based on a specific characteristic (such as the supported texture compression formats), and thus, each APK will declare support for different devices. However, it's OK to publish multiple APKs that overlap their support slightly. When two APKs do overlap (they support some of the same device configurations), a device that falls within that overlap range will receive the APK with a higher version code (defined by android:versionCode).

App file size differences in Android and iOS

Working with both app distributions services (android market and Apple App store) I have discovered a mystery.
The file size of an app is in general larger for an Apple app than for a Android app.
I can't seem to find any explanation for the differences, and it seems to be an untouched subject.
I have tried allot of different apps and the difference seems to vary between a couple of MB to 6-8 MB. So the question is, how come the file size is larger for Apple apps? What is the extra MB used for?
Examples:
BBC:
Android: 918K - https://market.android.com/details?id=bbc.mobile.news.ww
Apple: 6.7 MB - http://itunes.apple.com/dk/app/bbc-news/id364147881?mt=8
Due to some spam prevention, I'm unable to link directly to the rest.
British Airways
Android: 1.2 MB
Apple: 7.9 MB
Northern Bank
Android: 2.1 MB
Apple: 6.4 MB
Bank of America
Android: 727K
Apple: 2.1 MB
I could go on... If anyone can provide a statistics of file size for the two app distributions, confirming or disproving my theory. - I would appreciate it allot.
I have just spent the last day or so trying to track this exact problem down. I have built a little game called BlockIT for Android, and now I have a running version for iOS. The extremely odd thing is that the Android version is 8.2 MB and the iOS version is 14.1 MB.
Now, since I am the owner of the source, I wanted to track this down and find out why. As many suggest here that it is the graphical elements - this is not the case. The entire data set (non code) was almost identical in each package. Which makes sense since I am using the same graphics in each application.
So, why is the code build so much different! My iOS code build was nearly 7 MB and the Android one was less than 3 MB. The code itself was written to run identically and all but small portions of code are exactly the same on each platform. What I found was that the build (iOS gcc) settings had massive effects on what size of output you get. If you set only to target ARM6 or ARM7 then the size of my code binary dropped from 7 MB to 5 MB. This indicates there are almost complete duplicates of functions and libraries for each target in the one binary! Additionally, the built-in debugging symbols dont seem to get entirely stripped. Finally, the encryption of the code also costs large amounts. This is probably the most puzzling, since Android signs their apk's in a similar fashion. It seems that the iOS signing is done very oddly.
So, I hope that helps. To reiterate:
- Images / Data don't seem to be the problem
- Code building on iOS generates multiple platform output in the one binary == lots of extra code (btw I dont wee why Apple does this - seems odd).
- Code encryption is not very size friendly on iOS.
There's no real way to fix the actual problem (again, odd and disappointing).
The binary executable in an iOS app is encrypted, and thus compresses very poorly or not at all. The binary executable in an iOS app is compiled with some library code statically linked, which can often make it larger than interpreted Dalvik byte code for similar stuff. iPhone apps tend to contain more high quality graphics content and artwork for multiple screen resolutions including the relatively large iPad display.
For a universal app in iPhone we need to put three size of images -
one for 320x480 px
second for 640x940 px (retina)
third for 768x1024 (iPad)
where as while developing a android application we need to put three kind of images -
hdpi (high)
mdpi (medium)
ldpi (low)
one more thing here in android there is no compulsory rule to put all three kind of images. Basically it depends on for which target you are making app , only for those resolution we need to put images.
In my opinion, Apple Developers are using more full-screen size Images (in low def and Retina), and much more images than Android, and UI definitions files for iPhone (.XIB) are much bigger than XML files used in Android. There also should be a difference of Compression in packaging (.APK) is so hugely compressed ! And Finally maybe a difference in Including frameworks, but on this point I have no clue :)

we have Android Application Size more than max Size?

What should we do if the size of our Android application is more than max size? Currently the acceptable size for Android applications (i.e. <App>.apk) on the Android market is 50 MB.
If our <Application>.apk size is more than 50 MB then what's the alternative to follow on?
Try removing the resources from the project and changing the app so that the resources will be downloaded upon first app opening to the SD card...
It will take some time to develop the changes, but I don't think you really have a choice...
Note that Samsung devices have an even smaller size limit...
The first reason for .apk size growth is resources. The more specialized application gets on each configuration (screen sizes, orientations, densitites etc) the more .apk size grows. Usually .apk still has size much less then 50 mb limits, but even with 20mb users may perceive your application as heavy.
Android Market added support for multiple .apk per application. This feature was designed to specifically address the issue of .apk size growth due to many different configuration. You can read more about it in Multiple APK Support in Android Market post from official Android blog. Though this is considered as last resort.
If you .apk size is large due to other reasons, then you're most likely doing something wrong. If its some embedded video/audio file (or even files!), consider moving them to web and download when user needs them for the first time. This will save internal memory space which is might be critical to users (especially on older devices).
I can't image why an application would be more than 50 mb from just the source code alone. If alot of the size is in design elements(images, etc) or data(database files), you could always have the user download this info when the application is first run.
if you are using Android 2.3.3 version then minimum size of the application must be minimum 9MB and maximum size is depend upon the device,the capacity of memory of the device. but if you take it 50 MB then no problem, its disadvantage is only that the AVD takes time to start.i don't know the Android Market place current application size.

shall i do android tablet version project in same or as different project?

We have developed an app in medium(320x480) and high (480x800) supporting portrait and landscape. App has so many images so the build apk file size is 27 MB up to now.
Now client wants app in tablet version. If i do tablet version in the same project i think app size will be reach to more than 30MB.
Is there any problem if the app size reaches more than 30MB ?
Shall i do this tablet version in the same project or in different project. Please suggest me.
Thank you
Your application may not work as expected on Tablet if
1) you have used Android APIs that have been deprecated in HoneyComb version (Android version for Tablet). This begs using new APIs, worst case redesign.
2) you have tailormade UI widget for 320x480. This could include hardcoded resolution values, small resolution images used in UI widgets. In this case you need to redesign your UI Screen and fine tune it for Tablet.
3) your workspace in Froyo /Gingerbread. You need to migrate your application workspace to HoneyComb.
4) your app has put any limitation because of hardware. This I derived from the fact that your current app has been developed for 320x480 resolution, must be a slow hardware. But Tablet are powered by 1 - 1.5 GHz processors. You may need to have a look at new set of limitation (or freedom ?). For example memory limit on application may have gone up.
In short I would suggest have a different workspace for Tablet, however if your application has classes that are independent of above stuff, then you can share your package across application. (Tablet Vs Phone App).
Shash
Is there any problem if the app size reaches more than 30MB ?
If you are planing to upload your application to android market there is a file size limit of 50MB for an apk file. Other problems related to large apk files are listed in this SO question
Update:
Google updated their market policies you may refer this link

Categories

Resources