I know that android version 2.1 and below do not support GLES20. My code can run with both the fixed function pipeline (GLES1.x) and the programmable pipeline (GLES20) based on runtime determination of the version used by a android device and setting the GLES version accordingly.
My situation is that I would ideally like to keep my GLES20 code in my project and just not use the classes that use GLES20 at runtime when an android device of version <= 2.1 is detected. But when I set my project to 2.1 in Eclipse, GLES20 creates a compilation error. I assume that this is so because the Android2.1.jar does not contain GLES20 .
Is their a way I can keep my GLES20 code without getting compile errors when setting the android version lower and to just not use the GLES20 code at runtime, so that the running code will never use the GLES20 portions anyway.
Thanks
Okay, I figured out how. The element minSdkVersion and targetSdkVersion in the manifest allows this. I quote from the "Beginning Android Games" book. "This element allows us to deploy an application that uses APIs that are only available in newer versions to devices that have a lower version installed". So I will use this element accordingly, and develope in eclipse with my target android version set. I'll answer my question with this asap
The relevant documentation on Android developers, as linked by Mārtiņš Možeiko's comment.
developer.android.com/guide/appendix/market-filters.html
Related
Basically, I have to make ML-based application in Android Studio. I already make and trained my ML model and converted it into the TensorFlow Lite model. But when it comes to the android studio while configuring my project there's an option for minimum SDK. As far as I know, you have to select the minimum SDK level so that your application can run on every android version. In that case, how can I ensure that ML-based application will work fine on the older android version?
This is the reason I am asking what would be the minimum SDK level for ML-based application.
minimum SDK level is used to determine minimum API you want your application to support. It doesn't quite related to your tflite model.
I think what's most important is that you pull in correct tflite runtime which has all ops that your model uses.
Not sure whether you model has metadata. If it does, maybe you can use ml model binding so you don't need write too many boilerplate code.
First some premises:
Android applications make use of Android SDK API classes.
A class definition is some code or parts of code, which gets compiled into machine code/bytecode.
I assume that all (or most of) the classes/packages that make up Android SDK API are listed under:https://developer.android.com/reference/packages.html
https://developer.android.com/reference/classes.htmlWhich is a lot!
Now the question:
Where do these codes/data reside? Are they compiled along with the application code into the APK file or do they exist inside the Android OS on a device, in which case the application should dynamic-link to them?
If they're present on the device, then what difference does it make to compile the application with newer Android SDK versions (per compileSdkVersion in Android Studio for example)?
Let's say the "Android SDK Build-Tools" (which is not the same as "SDK Platform" (according to "SDK Manager" window!) and has its own versioning) takes care of compiling your code and therefore newer version mean better bytecode optimization and faster JAVA -> DEX translation!?
Does "SDK Platform" which you compile your android application against and set it's version with compileSdkVersion keyword, contain solely class declarations and reference-symbols?!
What about Google APIs (e.g. Google Maps API)?
What about Android Support Library?
The Android SDK code is baked into the device, and is not part of your apk.
Stuff you need to include via gradle compile gets into your apk (e.g. Support Library)
The Android core SDK classes are provided by the Android runtime instance that runs per App, you might call it the Android virtual machine if you will. When your App needs to load a specific Android framework class, a Classloader will load it for you in a process similar to dynamic-link as you mentioned.
There is not much you can do to change the version of the framework running on the device. However, the reason you need to specify the different minimumSdk and targetSdk, is for the lint/compiler tools to indicate you what functions/apis might not be present at runtime in specific framework versions. Based on this information you provide wrappers/adapters or simply if/else logic to provide an alternative functionality or simply to avoid a ClassNotDefinedException or MethodNotFoundException at runtime. It is basically a dev tool to help you visualize what could be wrong with other versions different from the one you are compiling against.
Certainly when you compile it, it produces references-symbols in a similar way as if reference an included library. The VM Classloader will resolve the actual file to load at runtime. Not quite sure how Google Apis work but it might be provided as well, in the case of the support library it gets included as far as I know.
The minSdkVersion is manually set by the developer. But you can easily use a function at a higher level and not find out about it until runtime on a device that doesn't support it.
Is there a tool or compiler option that will warn you when you use a function that isn't supported by your minSdkVersion?
I'm using SBT, Scala language, and IntelliJ IDEA. Also using android-sdk-plugin for SBT.
EDIT: I see a difference between my project (written mostly in Scala) and a default Java android app. In the Java code, I get errors when trying to use functions that exceed the minSdkVersion. But in the Scala project the IDE and SBT build system both don't seem to care at all. I suspect I'm missing a setting in my build.sbt file via android-sdk-plugin.
The API level check is performed by a lint tool which is part of the Android SDK. The lint tool works on a Java AST and cannot do anything about code which is written in a different language. To have these checks work for Scala code, someone would need to write an equivalent tool for Scala, but I'm not aware of the existence of any such tool.
I am not fully certain that I am not making any mistakes when setting API level when developing under Eclipse so here are some examples which I am not 100% certain about.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
Yes this practice is correct and is done to ensure support for the latest android versions.
When you set a minSdkVersion, then that's thr lowest version of Android your app will support and compiling with ant/gradle will show errors ehen you will use methods introduced in newer api levels for an older one.
Deprecated means that another method has replaced this one and that this one will spon be removed from the Android source code, so developers are encouraged not to use them. But yes they will work until they remain in the source.
The android.jar is a dependency of the methods and stuff included in the android OS, stuff that you'd be able to call and no I don't think framework.jar plays a role in this.
All external libraries are referenced and added to the apk. BUT only some of the google ones, those that are not primary. (Take a look at the gapps packages, that'll give you some specifics. Link: http://goo.im/gapps)
I hope I got this right and helped you to understand.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
Yes. That way you ensure you're always using the latest build sdk.
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
Just make sure that older devices will not get to that part of the code, using Build.Version.SDK_INT. This will give you the current SDK of the device.
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
Deprecated methods will continue to work, but better alternatives are available. When you have the option to use that better alternative, use it. When you're supporting devices that don't have this alternative yet due to older versions, continue using the deprecated method. You might have to do some if else branching based upon the Build.Version.SDK_INT value.
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
The newer devices contain the code of the older devices. Therefore it is not necessary to keep references to other versions.
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
The class files in the jar will be packaged in the .apk. The Google Play Services on the device communicates with your app using those classes.
I am developing a tool helping to convert web applications to run them on Android devices using Atjeews Android web application server. I noticed that applications have common problems as
No isEmpty() method for String
No java.util.concurrent.TimeUnit.MINUTES field and many others.
If I look in Android SDK reference, then all these methods and fields are available, however the SDK reference seems covering Android 3.0.
So will it be true if I can state that all Android versions until 3.0 are JDK 1.5 compatible and I need only assure that I can compile my sources setting bootclass of JDK 1.5 runtime?
No. Many classes in the JDK are not in Android 3.0 or 3.1 for that matter, and will never be there. If you look here on page 15 (warning: pdf link), you'll find a graphical diff. Disclaimer: That is from a book that I co-wrote.