I tried to run This example from bigflake and I think that there is a mismatch.
they write "ExtractMpegFramesTest.java (requires 4.1, API 16) " so the minimum API required is 16,
but I look over the code and they use "import android.opengl.EGL14;" which required minimum API 17.
Has anyone encountered this problem and succeeded to solve it?(succeeded to save 10 frames on Android 4.1 device)
I've updated the site to have two copies of the source file, one that uses EGL 1.0 and one that uses EGL 1.4. I did a quick test with the SDK, creating an app for API 16, to confirm that it's no longer using post-4.1 APIs. I haven't tried it on an actual device running 4.1 however.
You can use MediaMetadataRetriever.getFrameAtTime in order to extract frames from a video file. It's available since API level 10.
Related
In order to resolve a concurrency issue, I'm using ConcurrentLinkedDeque which according to android documentation, is added in API-21.
However, I'm still able to run the code on a device with API-16 without any errors at all. Though it does highlight calls to its methods saying:
Call requires API level 21 (current min is 14):
java.util.concurrent.ConcurrentLinkedDeque#ConcurrentLinkedDeque
but that can be ignored using #SuppressLint("NewApi").
So, why is it possible? Why don't I get a ClassNotFoundException when running it in APIs below 21?
Image:
http://i.imgur.com/VhW7CcE.png
Not allowed to post inline due to low rep.
So today i tried to up a new version of my App to the PlayStore and was greeted with that error .*Shown in image.
Any ideas what could have caused it>?
Your new version supports only api 15-19 while your old version supported 19+. So what its saying is that if a user were to upgrade from API level 15-19 to an API level above 19, they would have to downgrade your app to version 4.0 which is not allowed.
Either make your new APK support 19+ aswell (ie support 15+ would work) or deactivate your old version and then publish the new version, being aware that anybody with API over 19 will not be able to update.
As for what is causing your API version to be 15-19, it is hard to say without seeing your manifest as well as you double checking that you set the APK settings correctly on upload.
I started using Java 1.7 and I'm still using Eclipse. In my Project I add extra data to the thrown exception, with handledException.addSuppressed(additionalException); and it was working so far.
But according to my crash reports, some old OS installed devices(Android 2.3.4) are crashing with StackTrace below. But it doesn't occur in my Nexus 5 which has Android 4.4.4.
java.lang.NoSuchMethodError: java.lang.Exception.addSuppressed
I'm not really sure if there is some additional steps needed to update it to Java 1.7.
handledException.addSuppressed was added only in API 19.
You should put if else loop surrounding this piece of code
Android 2.3 uses level 10 API.
addSupressed() was added in level 19. In the future, check what API level was being used during that time (2.3), then check the API to see if it was available during that API level
I am having trouble compiling and running the ActionBarCompat sample of Android 16. I have API level 16 as the build target selected, which seems to build fine, but when I try to debug these errors pop up. Of course I could change the min API level in the manifest, but what would be the point of that? I have made no changes to the sample, so how come it is not working properly?
Class requires API level 14 (current min is 3): android.view.ActionProvider SimpleMenuItem.java /ActionBarCompat/src/com/example/android/actionbarcompat line 129 Android Lint Problem
Class requires API level 14 (current min is 3): android.view.ActionProvider SimpleMenuItem.java /ActionBarCompat/src/com/example/android/actionbarcompat line 134 Android Lint Problem
Class requires API level 14 (current min is 3): android.view.MenuItem.OnActionExpandListener SimpleMenuItem.java /ActionBarCompat/src/com/example/android/actionbarcompat line 155 Android Lint Problem
I am thoroughly confused, any help would be appreciated.
UPDATE:
I have added the #TargetApi(14) annotations, then added Lint suppres newApi to one of the methoeds and now it seems to be running fine. I am even more confused. Could anybody shed some light on what's going on?
Sadly, these samples are not kept up to date for each SDK iteration.
-First thing first, you have setted a min of sdkversion = 3 ? That seems a little low to me. 7 (eclair) is I think the minimum version most projects should focus on.
Lower level versions have a ridiculous market share and it will keep decreasing.
-These are Lint warnings. Lint is kinda new to Android, this is why this sample does not take it into account. It tells you about potential problems in your code. This warning means you are calling a level 14 class in a code that can run on a level 3 terminal. You should try to remove them with an #TargetApi(14) annotation. This annotation tells to Lint that you know what you are doing and this code will only run for sdk version=14 at minimum.
-Also, if you want to use the actionbar with any version of Android, what you really want to use is the open source ActionBar Sherlock library. One step at a time though :-)
In your manifest, you define android:minSdkVersion="3", yet you are making calls to API level 14 classes/methods.
Lint will check these types of API calls and give you a warning.
Obviously in the ActionBarCompat the current API level is checked to ensure it is safe to make the call.
To remove the warning simply add #TargetApi(14) before the method where you make the call.
You need to change the Project build target to API level 14..in (project->properties->Android)
These are their requirments:
Due to the use of the native action bar and its related classes on Ice Cream Sandwich, the library requires that both it and your project are compiled with Android 4.0 or newer. The project also requires that you are compiling with JDK 1.6 in both your editor and any build systems that you may be using.
Several random customers get this exception every time I update my Android app. I've narrowed it down to two reasons, both related to using the jni.
The *.so library is deleted when the app is upgraded.
The *.so library is not upgraded when the app is upgraded, and the old version still remains.
The device reports do not signal that this issue is related to the OS version, memory, or anything rational. Rather than focus on why Android is having trouble upgrading the libraries, I'm hoping someone out there knows how to manually pull the libraries out of the app's APK and put them in the right directory when this error is encountered.
Seems like you probably have an ABI mismatch - or possibly a false ABI mismatch caused by an Android bug that people have been talking about, where a generic arm library may not be accepted when one of the specialized varieties is preferred.
As for your workaround... you cannot write to the lib/ directory of your app's installation, though you can put a library elsewhere if you use System.load() with a precise path/filename instead of loadLibrary() with just a library name. I don't think there's any official (as in future-proof) way to extract arbitrary contents from your apk, though it's fairly easy to do at present with the zipfile classes (with something perhaps such as Context.getPackageCodePath() to discover the location and installation-variable name of the apk)
Checking for the success of the library loading attempt and reporting information about the device if it fails might be as useful.