I am using Camera.Parameters.setPixelFormat(PixelFormat.JPEG) in my android 1.6 application. The documentation says this is deprecated, but the constant value is the same as the new ImageFormat...
Should I not worry about it?
Typically, when something in an API is set as deprecated, it means that it is only there for compatibility purposes with old versions, and will eventually disappear from the API for future versions of Android.
This means that you don't need to rush to fix it, but you should start worrying about it long-term, and eventually create a new portion of code to do the same task using the current supported API functions, so that when a future version of Android API arrives that does not support the deprecated methods/functions anymore, your application is already ready to work and target new and upcoming versions of the Android platform.
Related
I am just a beginner but i have some questions regarding the support library.
Every time google team add's a new Support version it deprecated the use in new Version, so because of this we have to redo the code again just to support new API level.Can't it be like this , you can have this library but you will be not getting extra features .Instead of just deprecating the entire work ? Because of this there is a lot of extra work to do while making android app.
Why was PreferenceFragment deprecated in Android P and what are the support versions for both libraries PreferenceFragment and PreferenceFragmentCompat also what addition features to do you get?
Android platform is amazing but it's difficult to understand this things . If a developer has made an app what is the guaranty it will work when android releases new version ? With every release something is deprecated either the feature or the whole library.
Every time google team add's a new Support version it deprecated the use in new Version, so because of this we have to redo the code again just to support new API level.
That is not the case. "Deprecated" in Android usually means "we have something that we would prefer that you use". So, while eventually you should try to move off of deprecated APIs, "eventually" could be on the order of a couple of years.
Why was PreferenceFragment deprecated in Android P
The native android.preference.PreferenceFragment was deprecated in Android 9.0, mostly because it inherits from android.app.Fragment, which was deprecated in Android 9.0. The fragment code has had lots of bugs over the years. Google is trying to steer developers towards using a library-supplied fragment implementation, as the libraries can be kept up to date, while older Android devices (unfortunately) do not get updates.
There is nothing stopping you from using android.preference.PreferenceFragment in Android 9.0 if you wish. Ideally, over time, you stop using it, but you do not need to drop everything and change your code tomorrow.
what are the support versions for both libraries PreferenceFragment and PreferenceFragmentCompat
AFAIK android.support.v14.preference.PreferenceFragment should also be marked as deprecated, as it too inherits from android.app.Fragment.
android.support.v7.preference.PreferenceFragmentCompat extends from android.support.v4.app.Fragment, and so AFAIK this is the one that you should be using in the short term.
The whole preference fragment stuff is a bit of a mess at the moment — I am hoping that Google settles this out and provides clearer instructions as part of the migration to androidx over the next few months.
I was going through the Android documentation and I came across below lines:
In a very small number of cases, parts of the API may be modified or
removed, although typically such changes are only needed to ensure API
robustness and application or system security.
Is there an example of such removal of public API?
It would be interesting insight for all of us, developers, to understand why an API is removed and what can possibly be removed in Future based on this previous history.
The Apache HTTP client was deprecated in API 22 and removed in API 23. In this case it appears that they only removed it from the stub library, so apps using it will still run on Android M. You just can't compile them for Android M.
Google has also effectively removed features by changing the way APIs work. An example of this was the change to ActivityManager#getRunningTasks(int) in API 21. The method is still there, but it no longer allows you to discover what other apps are running, which is what many developers were using it for. Another example is how network activity on the main thread started throwing a NetworkOnMainThreadException in Android 3.0. In both of these examples, the documentation described the intended use of the API long before they began enforcing it.
Even though I have done some app on android, I am still confused. Is it possible to use functions in SDK 4.0, and run the app on android 2.1 or lower?
I tried methods you guys mentioned but got an error -
Field requires API level 11 (current min is 7): android.os.AsyncTask#THREAD_POOL_EXECUTOR, if I change min to 11, the app can't install on android 2.1, so even I can use higher API, but it still can't run on android lower version...how to fix that?
From Kzinch's advice, set TargetApi to 11, then it's working!
If you want a program that runs on both SDK4 and SDK 2.1 you have two possibilities. One is to provide alternative implementations on your code when they are needed i.e., if some function from SDK4 is not available in the SDK2.1 then you add a conditional block to your code that check the SDK version and provide code for each branch.
The other possibility is to use the Android Support Libaries in order to use the same code for both SDKs (no conditional blocks required). If you need a function provided by the SDK4 but not for the SDK2.1 you can check if that function is provided by a support library. If it is you can use it and your code will run fine on both SDK4 and SDK2.1 without requiring any version checking. For instance, if you need to use the LruCache class which is available since API level 12 (and so not available on SDK2.1) you can use the v4 support library which provide that function and works on SDK2.1 and SDK4. So in your code you would use
import android.support.v4.util.LruCache;
instead of
import android.util.LruCache;
Yes, you can use functions from the higher API in your code, but you must make sure they are never called on the lower API in runtime.
You should make checks for API level in runtime and provide alternative implementation that exists for that API level.
Let me provide some simple example:
SharedPreferences.Editor edit = PreferenceManager
.getDefaultSharedPreferences(getActivity()).edit();
edit.putInt(KEY, VALUE);
if (Build.VERSION.SDK_INT >= 9) {
edit.apply();
} else {
edit.commit();
}
apply() method is a faster (asynchronous) implementation of commit() method, but it not supported on the API level less than 9. With the help of API version check it all works perfect for all devices.
Update #TargetApi annotaion may be used to suppress Lint warnings/errors for API checks.
it doesn't matter what SDK level you compile your code against. Important is which methods/classes are you calling/instantiating.
If you use any newer classes or methods your code WILL crash running on older devices.
The suggested method to deal with it is Lazy Loading: http://android-developers.blogspot.co.uk/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
and remember, I'm saying this about the SDK.
The compatibility pack is a library developed by google that you can add to any project and use the functions of the library without issues.
Furthermore, there're 3rd party libraries (such as the ActionBar Sherlock http://actionbarsherlock.com/ that aims to bring higher SDK level functionalities to lower SDK levels)
No. You cannot use methods from higher API, because the code to handle it is simply not present on lower version of API. You can, however target as high API version as possible, but you may take care to call these methods on right API. You can easily check that at runtime with. i.e.
f( Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB ) {
// code to be run on Honeycomb and higher versions
}
If you are using the API which are specific to higher version, then the app wont work in older version.As those are not defined in the older version it will throw an error.That is the reason we restrict apps before uploading into market using minSDK in AndroidManifest.xml.
I have been making a project on Android 4.0 and I have faced some deprecated types for the newer versions of Android. A black line has occured on the name of the deprecated things. However, in spite of the black line and the deprecation warnings, I can still use those deprecated classes and project is running successfully. I got confused about the deprecation. If they are deprecated how can I still use them and what does deprecation mean exactly? If I use the deprecated classes in my project, what can be the possible disadvantages that the project users can encounter?
Thanks for reading.
Deprecated means that they are likely to be removed in a future version of the platform and so you should begin looking at replacing their use in your code.
If they just removed the types then builds would break and people wouldn't be happy!
In terms of the effect they will have on your application's users, there shouldn't be any effects at all. However, when you come to update your software to the next version of Android you may find that the deprecated types are no longer there and your build will break.
Wikipedia has a good article on it here: http://en.wikipedia.org/wiki/Deprecation
Long story short only use the deprecated method on systems running too low of an API to support the updated method. This way you can support a wider range of devices while only using the deprecated methods when you have to to support the older devices. Code example below.
int sdk = android.os.Build.VERSION.SDK_INT;
if(sdk < android.os.Build.VERSION_CODES.JELLY_BEAN) {
setBackgroundDrawable(); // deprecated method for older devices
} else {
setBackground(); // updated method for newer devices
}
CHEERS :)
Don't forget that there is probably a reason for these classes to be deprecated. It might affect the security or stability of your app.
If you find out there is a bug or a flaw it will probably never be corrected.
Also checkout what classes they advise to use instead, if any.
Concerning your worries about newer Android versions:
Android versions are backward compatible
Confirmed here by an Android engineer in a topic about an other deprecated class. Therefore you should be able to use your app on newer versions.
If you want your application to be compatible with older versions of android while using a "new" class in your code, check this related topic.
often some types of classes are deprecated but you can still continue using them because to update applications and implement those classes you would have to modify the source code.
But if you find that there are unused classes is better than in coming soon applications no longer use them, personally I spend it with ClipboardManager and use applications where previously it still works.
I see quite a few good old useful methods or even entire classes being "deprecated and obsolete".
But code that used to call those methods continues to work. So, what does this mean to me, as an Android applications developer?
Continue using this method as long as I want, because newer SDKs
will always remain backward compatible.
It will work as long as I build for older targets (e.g. API 8), but
if I build from API 14 up, the compiler will refuse to complete
the build.
Both (1) and (2)
Other?
This is especially confusing when no alternatives are provided, as in the case of WebView.PictureListener.html#onNewPicture.
It usually means that there's either a better way of doing things or that the deprecated functionality had some irreparable flaw and should be avoided. You can usually keep using deprecated methods, but you are advised to either switch to some new API (in the first case) or find some other way of doing what you want (in the second).
Regarding onNewPicture in particular, the entire PictureListener interface is deprecated. There's no sign of what, if anything, is supposed to replace it. A comment by #CommonsWare in this thread is food for thought:
It is conceivable that upstream changes in WebKit are driving the deprecation and that support for PictureListener might be totally lost in some future release.
I would go with 4:
It will basically tell you that the use of the method or class is discouraged; it is NOT 100% that they will keep backward compatibility (they can decide to not include that method in future releases), so you should try to use the replacement of the method or class. This is sometimes not possible to use the new methods (for instance, if you want to support devices running older versions).
Some other times it is actually possible. For instance, the showDialog method is now deprecated and they recommend to use DialogFragment class. You can achieve that even in older versions of Android by using the compatibility library.
Deprecated methods are not guaranteed to remain backwards compatible. They might remain in there for a few more releases just to give everyone a chance to migrate away from them before the developers remove them. The fact that they're deprecated means that the developers think that there's an easier, faster, neater, or otherwise better way to do whatever that class or method does.
It's probably better to change your code to use a non-deprecated interface now, since if you wait and it does get removed, your users will see crashes and errors.
Even when they are deprecated, they may compile but not work. Google has decided to delete various functionality at the low OS level.
Case in point. Google, at android release 2.3 deprecated many but not all method API's that allowed call recording. They compile OK but do not function since Android 2.3 and forward on any android phone device, or tablet with phone capabilities.
As an example for a deprecated interface that has been removed in a later API level, consider the org.apache.http package: It has been deprecated in API level 22 and removed in API level 23.
Of course on actual Android devices, the classes contained in that package will still be available in the system libraries (otherwise, applications targeting an older Android release would no longer run on that device).
They are however not available in the SDK anymore, so compilation will fail unless you either change the target/build SDK to an older version (or manually include the deprecated classes).
If Google were really determined to discourage use of those libraries, they could modify the implementation so that the affected classes check the target API version of the running application and complain and/or throw a runtime exception.