Android SDK Tools 21: Help in Compile with tab - android

Recently I updated SDK, and this new 'compile with' option appears.. what does it mean?

It means that despite targetSdk, "compile with SDK" version will be used. This is helpful to target higher SDK and avoid accidental use of newer API. Or, in other words, you want to target API17 but stay compatible with API8 without much effort. So you set target to API17 but compile with to API8. Now, if you code for any reason use anything that was introduced in API9 or up it will not compile. Previously app was build with API version set as target sdk
EDIT
After closer look I think this is broken. It is basically not saved neither in project.properties nor elsewhere, therefore it does not really serve described purpose, outside "New Project Wizard", which will generate code/layout stubs to match "compile with" API version.
Filled bug report: http://code.google.com/p/android/issues/detail?id=40286

Compile With is the platform version against which you will compile your app. By default, this is set to the latest version of Android available in your SDK. (It should be Android 4.1 or greater; if you don't have such a version available, you must install one using the SDK Manager). You can still build your app to support older versions, but setting the build target to the latest version allows you to enable new features and optimize your app for a great user experience on the latest devices.
source

Related

Should the Android compile version be same as the target version in Eclipse?

I need to set the target SDK version of an Android project to API 14. But I do not have the same version available to compile the project. I know that the project can be compiled with a different version but I need to know whether it will cause any issue.
I received the error "Android manifest file is missing" even though it exists. When I cleaned and then built the project it was compiled but the application crashed. What am I doing wrong here?
These were my settings.
There should be no issues introduced when compiling with a higher version, it is even encouraged to do so. You can find more on that topic in this Medium article.
I would also like to bring your attention to the following blog, which contains some important information regarding SDK targeting in the near future.
Unfortunately I do not use Eclipse so I fear cannot provide any verified insight on that matter. However the suggestions I have found so far include:
Cleaning the project
Getting rid of characters such as ö,ë, etc.
Deleting the file and recreating it
The manifest issue was probably due to creating a project with the same name over and over again. However clean -> build the project helped me get rid of it.
Yeah. Android compile version can be higher than the target version.
Android compile version and target version do not have to be the same.
compileSdkVersion
The compileSdkVersion is the version of the API the app is compiled against. This means you can use Android API features included in that version of the API (as well as all previous versions, obviously). If you try and use API 16 features but set compileSdkVersion to 15, you will get a compilation error. If you set compileSdkVersion to 16 you can still run the app on a API 15 device as long as your app's execution paths do not attempt to invoke any APIs specific to API 16.
targetSdkVersion
The targetSdkVersion has nothing to do with how your app is compiled or what APIs you can utilize. The targetSdkVersion is supposed to indicate that you have tested your app on (presumably up to and including) the version you specify. This is more like a certification or sign off you are giving the Android OS as a hint to how it should handle your app in terms of OS features.
As for the manifest error, you could try (if you are using android studio) clicking File > Invalidate Caches / Restart or force a gradle sync
Thank you for your answers.
I think the manifest issue was due to creating a project with the same name over and over again. However clean -> build the project helped me get rid of it.
Yeah. Android compile version can be higher than the target version. Those two do not have to be the same.

What version of Xamarin.Android.Support do I need from nuget for minimum Android 5.0 API 21 (Lollipop)?

When I create a Universal Blank App and attempt to upgrade my NuGet packages, it tells me
Could not install package 'Xamarin.Android.Support.v4 25.1.0'.
You are trying to install this package
into a project that targets 'MonoAndroid,Version=v6.0',
but the package does not contain any assembly references
or content files that are compatible with that framework.
For more information, contact the package author.
I understand that I need an older version of Xamarin.Android.Support.v4, but I couldn't find any reference guide on which is the latest version of the NuGet package works for my build. Is there a place I can look to find this information ?
You can look at NuGet.org.
This error message is telling you that it requires MonoAndroid 6.0 to install into. This means that you need to set your <TargetFrameworkVersion> to 6.0 or higher. This is also synonymous with setting your Android version to compile against 6.0.
https://developer.xamarin.com/guides/android/application_fundamentals/understanding_android_api_levels/#framework
Please note that you can support APIs all the way back to whatever your MinSdkVersion is set to. It is not dependent of your TargetFrameworkVersion, as this is a common misunderstanding.
https://developer.xamarin.com/guides/android/application_fundamentals/understanding_android_api_levels/#minimum
My advice is to compile against the latest API version and to set your minimum API version to the lowest level you need to consider. You can read more about that here.
https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#considerations
Finally to see a historical version history of this library, you can simply search on NuGet.org:
https://www.nuget.org/packages/Xamarin.Android.Support.v4/
Please note that you will most likely need to download the lib via the download button on the side, extract the nupkg and view inside the lib folder which will be named the respective target you need.

Is Android SDK compiled/linked to APK or installed on Android device?

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.

Picking API level for Android app in Eclipse and manifest

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.

Problems editing target in project properties

I have a library project whose target in project.properties is android-11. I wanted to create an app which uses that library, but compatible with android 4.1.2, so i edited also the library target with android-16.
But when i've done this change, the application gave me some problems and didn't work as before: for example in devices with software menu buttons, the buttons did not appear.
Can you tell me why? Thanks
first of all pls goto the SDK manager and check if you have SDK for Android 16 or above installed. If not please install it, if you have already installed then don't change anything in then project.properties, goto AndroidManifest.xml and make sure that "maxSdkVersion" is equal to above 16, if not it means that the library is depreciated and you cannnot use it for latest version. But generally most of the old libraries would support new SDK builds, so I suggest you to leave it as android-11 as it makes no harm
<uses-sdk
android:minSdkVersion="3"
android:maxSdkVersion="16"/>

Categories

Resources