The minimum SDK version for my project is 7, I am not able to use TrafficStats out of the box. Therefore, currently I am using an approach based on reflection as shown here. The main problem with that is that I cannot have this stats on devices with earlier than Android 2.3, it just gives me the possibility to do not Force Close on a 2.1 device.
Then now I am looking for a way to use the TrafficStatsCompat as it is described on the doc as "Helper for accessing features in TrafficStats introduced after API level 14 in a backwards compatible fashion."
My main problem is that I could not find any example on how to use this compatibility class. I've been looking for other classes inside the support library so I could try to mimic the behavior on how to use it, but I was not successful. Can someone provide an example on how to use the TrafficStats methods, e.g., getTotalTxBytes, but with TrafficStatsCompat.
Can someone provide an example on how to use the TrafficStats methods, e.g., getTotalTxBytes, but with TrafficStatsCompat.
No, because that class has nothing to do with accessing traffic stats on API Level 7. It does precisely what you quoted: it helps developers use methods added to TrafficStats after API Level 14.
There is no way for you to get traffic information prior to API Level 8 when TrafficStats was introduced.
UPDATE
Since trying to answer the comment in a comment was going to be painful...
You only need to play reflection games like that if you are continuing to support Android 1.x (and if you are, you are a saint).
If you are sticking to Android 2.x and higher, you can simply route using Build:
if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.FROYO) {
// do something involving TrafficStats
}
You should add to your project (into lib folder) following library android-support-v4.jar (android-sdk\extras\android\support\v4)
Related
The entry page of Android's DRM documentation [1] says that
Android provides a DrmManagerClient-native implementation as the interface to native modules.
From what I can tell, the interface is DrmManagerClient.h [2].
When it comes to the Java API, it's clearly stated that only API level 18 and higher supports the modular version of Widevine. API 18 introduced the MediaDrm class, while the NDK contains a NativeMediaDrm.h from API level 21 on. Newer Androids comes with "libwvdrmengine.so" and "libwvm.so", which could be one library for WV modular and one for WV classic. An Internet search shows libwvm.so being used on Android 4.0.4 and later.
Which Android-versions support Widevine-modular in DrmManagerClient-native?
[1] https://source.android.com/devices/drm.html
[2] android/platform/frameworks/av/include/drm/DrmManagerClient.h
I wouldn't put so much trust on documentation. For example, it's 6 years they still have to adjust it to reflect commit 0a32d7981b98fdfca48a1e35ca746f1cc11849d3.
Anyway, Widevine-classic was actually introduced in 3.0, but aside of the changes for the introduction of modularity you mention in 4.3, I'm not aware of any other special trick.
According to this the libraries you are talking about are not to be considered "separated". My educate guess is that after Stagefright they just "compartmentalized" everything involved with media reproduction as much as possible, even DRM. But WV is still only two paths.
For my new assignment, I wanted to use some library that can provide a "Posterize effect". I found many library like Aviary SDK and jhlabs, Yes, these are easy to use, but these making the code heavier. SO I keep searching for Android's API itself which can do the similar task. And after a lot of RnD, I finally found one my time saver class EffectsFactory which provides the same as I wanted. I applied it in my assignment also. But the bad thing it was added in API level 14, And my app should be compatible with at least API level 8.
So, My question is,
Can I use EffectsFactory class for lower version? If Yes then How?
Or, If No, Then Do we have any API in Android SDK itself which do similar to effectfactory ?
Please avoid referencing any library or NDK's open cv library.
No, there is not an Android API that will posterize an image below API 14. Even above API 14 EffectsFactory may not work, as it says in the Android documentation:
Some effects may not be available on all platforms, so before creating a certain effect, the application should confirm that the effect is supported on this platform by calling isEffectSupported(String).
However, you could easily make a lightweight solution yourself. Posterization is a simple process. For example, the code behind JHlabs' posterize filter is less than 50 lines (and most of them are sugar). In your shoes, if using a 3rd party library was out of the question, I wouldn't hesitate to write my own.
Edit: If you happen to be posterizing images your app takes from the camera, there is also Camera.Parameters.setColorEffect(), but again this is not supported on all devices, as it says in the documentation:
For example, the application should call getSupportedColorEffects() before calling setColorEffect(String).
Well we started an application with support from API Level 8 i.e Froyo verison. Now we being on API level 18 Jelly Bean version, how do we stop using deprecated API's on my application.
One Example
Dialog(API 1) vs DialogFragment(API 13)
Following are in my mind
1)Use Android Support Library Good way to go?
2)Have a runtime API level check as below, is this a healthy habit?
if (Build.VERSION.SDK_INT==Build.VERSION_CODES) {//Some API Level
run a code
}else if(){
run a code
}
3) Use reflection?
4)Have separate code base to each API level,makes no sense.
5)Does Palystore allows us to uplaod multiple Apk's based on API level.Or the complete control is on uses-sdk manifest value.
<uses-sdk android:minSdkVersion="integer"
android:targetSdkVersion="integer"
android:maxSdkVersion="integer" />
What will be the best way use latest API's with only one code base and make one APK and inturn have backward comparability support.
Inputs will be much appreciated.
One Example Dialog(API 1) vs DialogFragment(API 13)
Dialog is not deprecated. Ways of using Dialog may be deprecated, such as the old-style managed dialogs.
Use Android Support Library Good way to go?
Generally, yes.
Have a runtime API level check as below, is this a healthy habit?
Yes, though usually you use >= or <=, not ==, to drive behaviors for a range of API levels.
Use reflection?
I wouldn't.
Have separate code base to each API level,makes no sense.
Does Palystore allows us to uplaod multiple Apk's based on API level
In some extreme cases this may be required. Most apps should not need this.
What will be the best way use latest API's with only one code base and make one APK and inturn have backward comparability support.
That is impossible to answer in the abstract.
Why not upload the existing application as a "legacy version" of the application, that supports older version of the app, and continue to develop the existing application for newer devices?
Android platform sample codes and reference from the Android developer site is based on platform 1.5 I understand that newer platforms can support applications developed on older platforms but the reciprocal is not applicable which makes sense but is the coding different? Are codes that were used for developing 1.5 apps still useful in newer platforms or have newer classes and methods replaced them? It seems that eclipse is producing a lot of coding errors in its samples in relation to classes and methods also if a app that was developd by a IME is unable to be viewed on the emulator or how can it be tested or retrieved on the device? Any advice is welcome...sorry it's so long
If you look in the SDK folders, on windows it will be c:\<SDK location>\samples\android-x the samples are located according to api level so they will definitely be compatible there so I would look at these.
To answer your other questions, yes there are api changes as you go up an api level so they should cause warnings or compilation errors and some classes may even be completely removed. Generally the lower level stuff shouldn't change too much but the most important thing is that the semantics change rarely unless there was a design flaw in the original implementations.
The release notes for each version usually points out what has changed and the online documentation is generally superb in my opinion in informing you what exactly is deprecated. If you are just targeting old devices then your emulator is just set to target those api levels but if you are concerned about functionality then you could code using api 1.5 say, and run an ICS api level 15 emulator and check everything works OK, if not then you decide what the best strategy should be. Generally I would advise to target Android 2.2 and above for mobile devices and 3.0 for tablets but really it is up to you.
three are classes that are deprecated and can't be used anymore, like Contacts.People. There are also classes that are deprecated, they can still be used but they should be avoided in new projects. And there are new classes that were not available before. In some cases like for Fragment there are compatibility support libs to use the new features on the old platform but this is not true for classes like for example PreferenceFragment that are not supported on old platforms.
I'm developing an Android app which will target 2.1/2.2 devices, so I have my project set up to use the 2.2 SDK (API level 8), but allow for installation on devices with at least API level 7.
The problem is that during my daily development, I'm not always paying close attention to which API level of the methods/classes/constants that I'm using, which makes it very easy to break code on older devices. I have got dynamic classloading working, and as much as I dislike having a ton of extra factory classes and interfaces in my project, I'm willing to deal with that solution. Currently, the only way I have to check an older API level is to set my project's settings to the given level, rebuild, see what breaks, and then refactor. It's quite a pain.
What I would really like is the ability to scan my code and check compatibility for a given API level without changing my global project build settings. Is there some easy way to do this?
Android API Analysis Plug-In for Eclipse:
http://adt-addons.googlecode.com/svn/trunk/apianalysis/
Ok, so based on my research and the comment by #CommonsWare, there's no static analysis tool or some other easy way to do this. Shucks.