My question is the following: can I have one application on the market, but when the user downloads it, depending on what OS the user is running, she downloads different file - one file for 2.2, other for 2.1, third for 1.5, etc?
No, that is not possible. However, you can have your application respond differently to whatever OS level the device is running. Use android.os.Build to find out what version you are on, then use reflection or conditional class loading to route your behavior accordingly.
OR you can create different apps for each target OS version, name their packages differently (for instance com.example.16, com.example.20 com.example.21) and in each Android.xml specify minimum and maximum API level to the one you target. So the 2.1 version will have both mini and max API level set to 7. Then you publish all of them to the market under the same name.
When a user with an Android 2.1 searches for your app he will see only the one with the package name com.example.21 thus fixing your problem.
It seems appropriate to note that Swype's approach to problems like this is to download an "Installer" application first. (It's not from the Market, but it could just as well be)
Swype's installer uses a login and password to contact a Swype server, and download and install the appropriate .apk for your Android device.
Generally this approach is impractical to a smaller developer, as it requires server setup, etc. But it's another possibility that I thought I should mention.
Related
My problem is there is a set of apps called good lock apps made by Samsung But they aren't supported by One UI core devices and some, not with android 11, So I would like to increase the API level of the application, add any android source code as well as somehow make it accessible by one UI core devices(By changing boolean).In Android studio, I tried the above but the code reverts back to the original, and am not able to run it, So can someone please say if the above is possible, if possible say how to proceed and if not please say what can be done alternatively, Thank you!
If it's a third party application, then the app would reside within data partition. And in any case you should be able to install the new version of a third party app unless you hold version number higher than the one present in the device.
While targeting SDK version higher than 25 make sure that you have REQUEST_INSTALL_PACKAGES to install a new application.
The other option is to uninstall the existing application (at your own risk), and reinstall the compiled version of the apk.
If you still face issues, please attach the logcat information while installing the apk, that could help us to look into the problem further.
My application needs to determine if the device has the latest OS software provided by Google.
For example, currently, I need to be able to determine if the device is running Marshmallow, regardless of the fact that the phone may not ever be able to install Marshmallow.
Will this need to be something that is hard-coded into the application?
Thanks
Will this need to be something that is hard-coded into the application?
Yes, more or less. You could use reflection to examine the values in Build.VERSION_CODES and see which is the highest in the continuous range starting with 1.
However, those values are compiled into your app; they are not coming from the framework, as they are static final int values. So, while this approach would work for current and future versions of Android, you have to build your app with the latest compileSdkVersion, ship that updated app (which will now pull in a higher max version code), and rely on users to update the app.
If you don't want that — for example, you don't want to rely on users updating the app — you will need to pull the latest-version information from the Internet, preferably from some host that you control.
I'm facing [LinearAlloc exceeded capacity][1] error when I try to install our app on devices running Gingerbread. So we decided to break our app in two versions: a light one with just some of our features (targeting API 8+) and another one one with our full features (targeting minSdkVersion=11).
My question is: should I set the light version with maxSdkVersion=10 in this case? The problem is that the developer guide highly recommends to avoid using this property. But I also would like the user to see only the best version of our app for his device.
Our project is really complex and the performance on old devices is becoming bad.
I've found some workarounds for this error but all of them uses Ant, and we've already moved to Gradle. And we still have a considerable number of Gingerbread users, we must consider them.
Is this approach ok?
The downside to adding the maxSdkVersion is that should the device get upgraded in the future your app would be removed in the process.
You have to wonder if someone would bother upgrading a 2-3 year old device though or if there is even an update available.
However, to cover all scenarios you could simply add a check in the "light" version that notifies the user that they can install the full app on a device with SDK >= 11. You could also link to it directly in Google Play.
You may try bringing multiple APK support to your app.
http://developer.android.com/google/play/publishing/multiple-apks.html#HowItWorks
The answer to your question
Should I set the light version with maxSdkVersion=10 in this case?
is here:
You should avoid using android:maxSdkVersion in general, because as
long as you've properly developed your application with public APIs,
it is always compatible with future versions of Android. If you want
to publish a different APK for higher API levels, you still do not
need to specify the maximum version, because if the
android:minSdkVersion is "4" in one APK and "8" in another, devices
that support API level 8 or higher will always receive the second APK
(because it's version code is higher, as per the previous note).
So differentiating your APKs in their manifests by only specifying different android:minSdkVersion values should be enough.
How should I make the choice ? What are the parameters I should take into account ?
First of all you should take into account relative number of devices running a given version of the Android platform
Have a look at Android versions market share. I would develop for 1.6+. If you will realize in the middle of development that you want some API feature from newer version, you will have 3 choices:
Don't use that feature
Detect Android version from the app and then decide what to do
Change required Android version in your manifest file and project settings
If possible, you should support the oldest Android version still in widespread use. That would be 1.5. If you need features from later versions, you might consider requiring newer versions, but if you can do your work on the oldest version still available, you should to increase the number of people who are able to use your app.
The Oldest version that supports all the functionality your application requires.
For example: Your app needs multitouch? Target version 2.1
My application doesn't need any functionality introduced in newer versions, so I target 1.5
I agree with the answers posted above, and I would add that on the android API reference site, most of the time the minimum API level is specified (http://developer.android.com/reference/android/package-summary.html).
You can have a look at this page to identify the Android version associated with a given API level: http://developer.android.com/guide/appendix/api-levels.html
Personally, I develop everything for 2.1. There are only a handful of devices that still run <2.0 and most of those people have already put custom roms on them already. I know it kind of screws people with older phones, but I don't like the idea of crippling my app just to make it backwards compatible.
Also I feel like developing for >2.0 encourages people to upgrade their phones =P
#Falmarri: I see some flaws in your logic. Usually I'd tend to follow the same path as you if I'd be developing on another Plattform, like Windows. I do my C# applications always against the latest (non-beta) version available, as the .NET Framework is freely available for everyone (take out the new releases not being available for Win2k, which is almost 10 years old now).
With Android this attempt don't work. A majority of the devices which run 1.5 and 1.6 do it because there is no update for this device, as the manufacturer stopped developing new versions for this phone (either to motivate users to get a new upgraded one) or because it's to time intensive to make backports to this "old" devices.
So this uses don't have the "free choice" of upgrading their phones. Technically it's possible of course with rooted/custom ROMs, however most users do not have the technical knowledge to root/flash their devices with custom ROMs or don't want to lose their warranty.
So if you want to offer your App to as much people as possible, you have to develop it in mind with a much older OS version. In Android case, against 1.5.
And this is basically what I do. I've done my Apps with 1.5 in mind.
If you are developing using Android Studio:
1. Go to Tools --> Android --> AVD Manager
2. Click the Create Virtual Device... button of the AVD Manager dialog.
3. Select a Device on the "Select Hardware" wizard page of the dialog and click Next.
4. In the bottom right of the "System Image" wizard page you will see the following:
If you click the "API level distribution chart" link, it will provide you a summary of cumulative distribution by API level. I assume the information is kept up-to-date with each release. From there you can click on an API level to get specific information about that API level. Based on the information presented there, you need to use API level 18 or lower in order for about 75% of the current Android Market to be able to use you application.
Perhaps this is the type of information you are looking for. Hope it helps!
This is a direct quote from the Android Docs:
Generally, it’s a good practice to support about 90% of the active devices, while targeting your app to the latest version.
In a practical sense, this is impossible unless you had an unlimited budget.
Even Android themselves are only releasing security updates from version 8 onward.
As of right now, I recommend supporting Android 7 onward. This should cover 57.9% of market share.
If you scroll to the bottom of this page, there is a table that shows Android support information.
It will be updated monthly as the figures I quote above will change with time.
I've programmed my app with Eclipse and android 2.2. However I think that my app would work for previous version and so it would allow more users to use my app. The problem is that I'm not sure... for instance I'm using Gestures which I think is a more recent feature... but otherwise I'm just using some Button, ListView, and WebView.
So is there a way to detect automatically the Minimum Sdk Version needed ( by checking which function my app is using) ?
I can't download the SDK of each previous version of android and test it until it doesn't work ...
Thanks
I can't download the SDK of each previous version of android and test it until it doesn't work ..
Why cant you? This is what the rest of us do. Create various different Emulators and test it out. I've released many apps by testing this way.
Take a look at the Compatibility page on Android's developer website.
It has some great information on how to make sure your application will work on different versions of Android and how to stop users from downloading the application if they do not have the right features on their device. In your case that would be the gestures feature.
To manage this, Android defines
feature IDs. Every capability has a
corresponding feature ID defined by
the Android platform. For instance,
the feature ID for compass is
“android.hardware.sensor.compass”,
while the feature ID for Live
Wallpapers is
“android.software.live_wallpapers”.
Each of these IDs also has a
corresponding Java-language constant
on the PackageManager class that you
can use to query whether feature is
supported at runtime.
To be totally sure you have to test your app against every platform version you target. Otherwise users of your app will do it for you (and that might be not good for app rating).
On the https://developer.android.com/about/dashboards/index.html page you can see the latest up-to-date platforms share info. So just decide how many potential users you're going to leave without your app :)