Hello fellow Android Devs!
My Question/Topic today is about the "Minimum SDK" we set for our Projects..
For years now, "API-15" (IceCreamSandwich/4.0.3) has been typical, covering 97.4% of users.
However, I've recently noticed now that "API-16" (JellyBean 4.1) has caught up, at 95.2%!
Over the past few years, the percentages were MUCH further apart, making API-15 the go-to.
SO, MY QUESTION IS:
Are there any advantages to setting API-16 as my Project's "Minimum SDK", instead of API-15?
For example, less need for certain support libs, or better compatability with anything, etc. etc.?
Basically, ANY reason at all why choosing API-16 as my "Minimum SDK" might benefit anything?
..Thoughts?
I've worked on apps with both 15 and 16 as the minSdkVersion. I would recommend a minApi of 16, particularly if you use SQLite.
Api 16 has:
SQLite 3.7.11. You now have setForeignKeyConstraintsEnabled for your SQLiteDatabase.
Up navigation. Api 16 supports android:parentActivityName in the manifest, so you don't also have to have metadata tags.
Font families in xml. For your password EditText, you can now set android:fontFamily=sans-serif, so it no longer defaults to monospace.
The drawback is that the Samsung Galaxy S2 runs on API 15, so if this is an important demographic for you, you'd be missing out on them if you use minApi 16. All of my new projects are minApi 16.
Android 4.1 (API 16) has Has offline voice recognition. Offline voice recognition enables you to perform voice actions, like dictating texts or using various voice commands, without an internet connection.
Related
Google has introduced some changes recently related to storage APIs in API 29 like scoped storage and we opted out by adding 'requestLegacyExternalStorage=true' in Manifest. But now when I targetSdkVersion 30, this no longer seems to work. Some of the files in the download directories were not listing (File.listFiles) after this change.
But now when I targetSdkVersion 30, this no longer seems to work
That is correct. Android 11 (API 30+) requestLegacyExternalStorage=true does nothing and you can no longer "opt-out". It was available in Android 10 to give developers a transition/grace period to be able to migrate to the scoped storage model.
Option 1: Migrate data in your app whilst still targeting API 29, then once you're migrated data is compatible with scoped storage you should be able to release an update targetting API 30 - https://developer.android.com/training/data-storage/use-cases
This can come with its own problems if users skip this version and updates directly from a previous version to the latest and you're stuck with un-migrated data you can't access.
Option 2: It seems that Google sees this obvious caveat and has included a preserveLegacyExternalStorage=true option when targetting API 30 to allow you to migrate data. https://developer.android.com/reference/android/R.attr#preserveLegacyExternalStorage
Going forward you can reference this table for deciding what storage "framework" to use based on the use-case: https://developer.android.com/training/data-storage
There is a potential that some apps simply won't be able to successfully migrate, based on how they interacted with the File API as Google's solution will not encompass all current use-cases and there might not be a migration path.
For instance, I released an app a couple of years ago that allowed users to update album artwork using MediaStore and ContentResolver to update the data for the album artwork image - this was stored in shared storage. Having looked at the Android 10+ AOSP MediaProvider source code it seems that apps that used to use MediaStore to update album artwork to point to a data file no longer works, simply because the MediaProvider internally creates its own artwork in a hidden .thumbnails folder looking directly at the mp3's and using a MediaExtractor, and never references the ContentValues that were inserted to reference the artwork. So even though you can update the artwork yourself, query the MediaStore for it and see it, other apps have to use ContentResolver#loadThumbnail in API 29+ that does not reference your updated values and either creates an artwork lazily, or picks the already generated file in the .thumbnails folder. Obviously, none of this is documented, and I got a massive backlash to my app with negative reviews, yet these changes were breaking changes and completely out of my control and took me looking through AOSP source code to find that Android had fundamentally changed behaviour.
(This wasn't a rant, but an example of how these changes offered no migration path because of fundamental undocumented behaviour to AOSP).
As stated in https://developer.android.com/about/versions/11/privacy/storage there are some changes regarding storage on Android 11:
Android 10 devices
requestLegacyExternalStorage will continue to work regardless of target sdk
Android 11 devices
new installation targetting sdk 29: requestLegacyExternalStorage value is respected
new installation targetting sdk 30: requestLegacyExternalStorage is always false
upgrade from targetting sdk 29 to 30: if preserveLegacyExternalStorage is set then requestLegacyExternalStorage is true (this is pure migration case and this state won't be preserved should user uninstall/reinstall the app)
You're pretty much forced to implement scoped storage at this point. Unless you're ready to migrate just keep targetting sdk 29 as there's no way to enforce legacy storage on Android 11 devices with target sdk 30.
update: play store requires target sdk 30 as of August 2021
Don't do this until early 2021 (said by google):-
If you want to target to android 11, you should use the MANAGE_EXTERNAL_STORAGE permission.
Visit this page for more details: https://developer.android.com/training/data-storage/manage-all-files
Applications that run on Android 11 but target Android 10 (API level 29) can still request the requestLegacyExternalStorage attribute. This flag allows applications to temporarily opt out of the changes associated with scoped storage, such as granting access to different directories and different types of media files.
After updating application to target Android 11, the system ignores the requestLegacyExternalStorage flag.
No need to call "requestLegacyExternalStorage=true" which is not working for Android 11+.
There is a new update in https://github.com/apache/cordova-plugin-media to cover the saving file path issue for android 11+.
If you update "/platforms/android/app/src/main/java/org/apache/cordova/media/AudioHandler.java" and "/platforms/android/app/src/main/java/org/apache/cordova/media/AudioPlayer.java" in your project, then it should be working.
https://raw.githubusercontent.com/apache/cordova-plugin-media/4093f7e14fe65f94ffbef072ed188a0205e78a59/src/android/AudioHandler.java
https://raw.githubusercontent.com/apache/cordova-plugin-media/4093f7e14fe65f94ffbef072ed188a0205e78a59/src/android/AudioPlayer.java
I'm new to android development.
I'm studying with outdated books, so I'm really confused about new methods.
I'm going to make a simple and light app which can be run even on old devices.
So when I created a new android project, I set "Minimum Required SDK" to API 8, "Target SDK" to API 22 and "Compile With" to API 22.
Does this setting mean the app can work on the devices of API 8, even though I use the methods of API 22?
I'm asking this question due to deprecated methods.
I completed almost a half of my app developing using deprecated ones.
Can I just replace them all with new ones?
Or do I have to prepare multiple codes using different methods to support different platform versions?
(deprecated methods for older versions, and new ones for newer versions?)
Does this setting mean the app can work on the devices of API 8, even though I use the methods of API 22?
Yes. min sdk version is used to restrict the devices running OS with API level < minsdk from using app. Your app won't be shown in the play store for those devices.
I'm asking this question due to deprecated methods.
I haven't faced any issues till now due to depreciated methods. However, I would suggest to use min sdk version as 14 as Google has introduced many UI tweaks and enhancements. If you do some market research, using minsdk version = 14 would cover around 85% android market.
Can I just replace them all with new ones?
Yes, you can.
Or do I have to prepare multiple codes using different methods to support different platform versions?
(deprecated methods for older versions, and new ones for newer versions?)
You can do it also. Older versions do not have support have fragments. Fragments improve user experience drastically for tablets. Similarly, material design for Lollypop devices is awesome. Thee are few examples where you can opt for API level specific implementation. However, it is better to switch for api level >= 14
To clear up your confusion:
Minimum Required SDK
The minimum version of Android you're going to support. To target the largest market share, I recommend API level 14 or above.
Generally, the lower the number, the more Android devices you're targeting.
Target SDK
Basically, all this is saying is what SDK have you tested your app with. If that's KitKat then you can write in the number 19 which is the API number of KitKat, for example. You can find a list of API numbers here. As you test your app with higher and higher versions of Android, you can increase that number.
Setting the Target SDK to be a higher number will mean that you target a lot more devices.
Compile With
Specifies what API number of Android you want to compile your app with.
By default this is the latest version of Android available in the SDK Manager. Should be set high to improve user experience.
Deprecated Methods
As to your question about deprecated methods: You can continue using them. They are deprecated in favour of a newer alternative that may or may not be better in terms of functionality.
Deprecated methods will still work, the deprecated keyword just tells you that there is a newer preferred way to do it. Android is really good at backward compatibility so something compiled for API level 8 should mostly work on newer devices to.
You're going to have to use multiple code branching on version. You can check your system version at runtime like this:
private void setUpActionBar() {
// Make sure we're running on Honeycomb or higher to use ActionBar APIs
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
ActionBar actionBar = getActionBar();
actionBar.setDisplayHomeAsUpEnabled(true);
}
}
API 8 is really old. Have a look at the version pie chart
You can find more information about this on the Android developers website
First off I need to tell you that I am new to java I have only been using it for a bout 3 weeks. I am putting together an app for our Electrical / instrumentation apprentices.
I developed an app using Microsoft Visual Studio 2010 Express for Windows Phone 7; unfortunately I am unable to run the app on a test phone with out paying Microsoft for a developer’s license for each phone at a cost of $100.00ea.
Is it possible to import and convert a Microsoft Visual Studio 2010 Express for Windows Phone 7 app in to eclipse and convert it for android?
Please tell me that this is easy to do!
Thanks
No. There's no easy conversion. It's a completely different language and system.
Your best bet is probably to load it into something like Xamarin and divide out your business logic into data classes, and learn the Android bits of Xamarin.
There's a ton of tutorials out there for using Xamarin's Android platform.
I'm just getting started with Android Dev.
Which Android phones should I add as virtual devices to make sure that my apps will work for the majority of people?
The only articles I've found from google were written 2 years ago, and I think the market share must've changed quite a bit by now, hence the phones listed there might no longer be in use as much.
Specifically I'd like to know which screen dimensions + Ram/memory I should provide to the phones for testing.
if your question is about which Android versions you want to support, you should check this link.
So basically you can use eclair (2.1) has the minimum supported version.
I highly recommend that you target the last version (Jelly Bean at the moment). It is a pretty good practice and this way you won't have to update your app to adapt it when JB will become more popular..
For my tests, I usually have a virtual machine with eclair or gingerbread and my phone with Jelly Bean.
edit : one very important clarification, in your app manifest. You will have to declare the minimum android version you support with android:minSdkVersion="XXX". the tag android:targetSdkVersion="XXX" is not here to tell on what version you are focusing, but to tell to the system if you have thought about the last versions. so you should always target the last one (16 at the moment). If for example you target gingerbread (api level 9 I think), then the terminal will assume that you did not adjust to the disparition of the menu button and display one, EVEN IF you don't even use it !! It is a very poor user experience.
As for the screens size to support, This link is very helpful (and whenever you have a question about android development the official website should always be your first destination). I think that the question is not really here are the screen sizes, let's make a layout for each one of them, but the contrary : here is how I want to display my app on a standard size phone (around 4.2" inches I would say), at which point in terms of dp do I need another layout because mine is either too cramped or has too much whitespace ?
If you really want to know what sizes to consider, somewhere between 4 and 4.5 inches is where you will find most high end smartphones of 2012. You will maybe need another layout for 3.5" or smaller screens.
In the superior dimensions, I would focus on 7" (Nexus 7, kindle, galaxy tab 7) and 10".
I am a noob to Android (and Java). I have successfully setup Eclipse and the Android Virtual Device (AVD). I am guessing the AVD's Target is the version of Android to be emulated, but I want to make sure. I am trying to develop something for my Droid X2 phone.
As such...
Which AVD Target is the right one for a Droid X2?
Is there an online list someplace explaining each Target?
...I have Googled both unsuccessfully.
Thank you for the help.
According to motorolas website, the Droid X2 ships with Android 2.2 (api level 8).
I'm not sure if there are any updates rolled out yet, so consider this the lowest version you will get for this device.
So target 2.2. or lower.
But just a general advice: If you want to ship your app to other people, it's usually best to target the broadest audience. So I recommend going for 1.6 as a target, that will still run on your phone. You can start to raise the target version when you notice that you need a certain feature (can be easily done from the "project properties" dialog inside eclipse in 5 seconds). If you don't seem to need any higher api features, you are way more compatible to many more devices this way.
Edit: To the targets. See Android API levels. Clicking on a version takes you to the changelog. Theres info whats new. Also notice that anything below and equal 2.3.3 is a phone os at the moment. Anything equal or above 3.0 is a tablet os.