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.
Related
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.
I'm using android-sdk-plugin to make Android apps with Scala using SBT. This generally works great - however when trying to import the project into IntelliJ IDEA 14.1 the imported project looks rather empty and does not recognize my source files as being part of the project.
The documentation says:
IntelliJ 14 now includes native support for importing projects from android-sdk-plugin. The process generally works well, however there are still several caveats:
The idea-sbt-plugin is still required to actually perform the build (no longer necessary as of IDEA 14.1)
Cloning and importing even the simplest example project results in an empty IDE not showing any sources at all:
I have installed both the Scala plug-in and the SBT plug-in (which I believe should no longer be required) as requested by the documentation.
What essential step am I missing?
Edit: I added the plug-in manually to project/plugins.sbt, then ran gen-android to get a project/build.scala containing object Build extends android.AutoBuild.
The essential step missing is the Android plug-in of IDEA. This might seem obvious but in contrast to plug-ins for other frameworks this one does not just provide extra goodies but is actually essential for anything Android.
Having the plug-in installed allows for selecting Android as a Project SDK (which not just selects an Android SDK but also a Java SDK to go with it).
I want to create a Java library like SLF4J which can run since certain Android version (e.g. Froyo/2.2).
The thing is, I can't be sure if some methods I use are already available on that Android version. For example, "String".isEmpty() is not available in Froyo. How should I know this, unless I create the library project as Android Library project?
Making the project as an Android library project is not easy to test. Robolectric is also tricky with Gradle.
I'm expecting something like simple Java Maven project which uses subset of Java API available in certain Android version. Is it possible? Like, I create a new SLF4J library without involving non-existent methods in Android.
Thanks
It's possible that there are differences between the Android SDK and other Java APIs, so if you build and test your code as anything other than an Android library, you may miss problems. For example, just the other day I found a bug in API 19 (Android 4.4) where DecimalFormat produces BigDecimals differently than it does in J2SE SDKs.
But if you must do this, the easiest way is probably to create it as an Android library project and build it against the Froyo SDK to ensure all the methods are available. Then take the same code and create different build files to build it for your preferred test framework.
I developed my java code using awt classes. When I copied this code to my Android project I was getting errors. So I added JRE system library to the build path. Will it work now?
No. The Android UI isn't built on AWT. (A few AWT classes are available, but not many - fonts, basically.) You should only use the libraries listed in the Android developer documentation.
No when you move it to an Android platform.
Android is a language that uses the Java syntax/keywords but implements a different API. As long as they could the kept it and copied it (see the more common classes like java.lang.String), but sometimes they could not
If the class is missing in Android emulator it will be missing in the device, and more likely that not you will not be able to port it.
I'm new to Android development and I wonder if I can use some Java packages (for instance javax.xml.bind, org.springframework or org.jooq) on Android platform despite the fact they are not listed on packages list of Android API. Is it possible when I simply import them as external JARs? At this moment I don't care if they are big, just if they can work on Android.
Thanks for help.
It Depends.
Android is built on a subset of Java 1.6. If the library uses references to classes that Android doesn't have, I believe the ADT plugin will give you an error about system level libraries WON'T work on Android. Something to that effect.
I wouldn't recommend it. The guys at Android included libraries that they knew worked with their system (and probably modified them).
Just importing a Java library that isn't part of the Android API and isn't written specifically for Android probably won't end well.
There are a lot of differences between mobile and Desktop computing.
As recommended by TeamMCS, try to import your librairies in your Android project. That's what we done with a SOAP client library and we saw that it depends on other Java librairies; librairies that are present in the standard JRE (i.e. Sun JRE on computer) but not provided with the Android OS.