I have a system of 2ig ram so I was recommended to download and install Android studio 1.5.1 with java 7...
But I already have java17 installed..
Any Reason why won't java17 work on older version of Android studio specifically Android studio 1.5.1
Each version of Android Studio is designed to support a specific (maximum) version of Android.
That version of Android requires a specific version of the Java compiler to create its packages.
Java 17 (and indeed all versions from 9 and up) aren't (fully) backwards compatible with Java 8 and below.
It's not that you couldn't run the later versions of Android Studio without having an older Java SDK installed (it comes with its own built-in Java runtime for that), but you won't be able to successfully compile things.
Recommending Java 1.7 however is a big nono, that version has been out of support for years. At the very least you want Java 8.
I've been trying to get started with Xamarin on Visual Studio Community 2019, but every time a new Android project is created and run, deployment is aborted and the warning below appears. I've already uninstalled and reinstalled both Java and VS, modified and repaired VS, and tried out different versions of the JDK, yielding no results. Any ideas on why this may be happening and how can it be fixed?
The current version of the JDK I'm using is 17.0.1
You can recheck if you have set up the Android SDK for Xamarin.Android correctly.
Xamarin.Android uses the Java Development Kit (JDK) and the Android SDK to build apps. During installation, the Visual Studio installer places these tools in their default locations and configures the development environment with the appropriate path configuration.
And for most users these default locations will work without further changes.
Xamarin.Android uses JDK 11, which is required for API 31 and greater, JDK 8, which is required if you are developing for API level 24 to 30 (JDK 8 also supports API levels earlier than 24).
For example:
For most users these default locations will work without further changes.
For more, you can check: https://learn.microsoft.com/en-us/xamarin/android/get-started/installation/windows#configuration
For how to set up the Android SDK for Xamarin.Android, you can check: Setting up the Android SDK for Xamarin.Android .
Note:
I recommend that you remove the older sdk and jdk files and use the latest version of Visual Studio with the default JDK and SDK Settings.
Does it support java 8 yet?
Eclipse is displaying this as a problem, surely it does support 8 by now? In the release notes for revision 23.6 it says java 7 or higher, does this mean java 8 is included or? Wish they'd be more specific about such details. Anyway, if it does support java 8 i cannot get it to work.
Android requires compiler compliance level 5.0 or 6.0. Found '1.8' instead. Please use Android Tools > Fix Project Properties.
The peculiar thing is, it's saying 5 or 6 yet it's allowing me to use 7 but not 8?
Does it support java 8 yet?
No. It doesn't. To date, no version of Android supports the Java 8 language.
Anyway, if it does support java 8 i cannot get it to work.
That is unfortunate. But don't give up hope just yet. Take a look at the retrolambda project.
I am a new comer to the android world and with a .NET background. I am trying to install the Android Studio but I am having a mismatch on Android.com about the JDK version required for developing Android applications.
From the SDK web page it states that JDK 6 is required (under system requirements section). Jim Wilson also insist in his course on Pluralsight (which is quite new, from last May) that using version 7 with the Android SDK will create a lot of headache and makes it clear to only use JDK 6.
Although in the Android studio page (Under installing step 2) they explain how to set an environment variable indicating the correct JDK location. In here they use a path of JDK 7
Select Start menu > Computer > System Properties > Advanced System Properties. Then open Advanced tab > Environment Variables and add a new system variable JAVA_HOME that points to your JDK folder, for example C:\Program Files\Java\jdk1.7.0_21.
I am pretty sure both the ADT & Eclipse bundle and the Android Studio bundle are using the same SDK but now I am confused about which JDK version I need to install. My sole purpose is to avoid problems as much as possible while getting my first steps into the Android development.
Disclaimer: I am not related by any mean to Pluralsight. I am just a normal user following the courses.
Answer Clarification - Android Studio supports JDK8
The following is an answer to the question "What version of Java does Android support?" which is different from "What version of Java can I use to run Android Studio?" which is I believe what was actually being asked. For those looking to answer the 2nd question, you might find Using Android Studio with Java 1.7 helpful.
Also: See http://developer.android.com/sdk/index.html#latest for Android Studio system requirements. JDK8 is actually a requirement for PC and linux (as of 5/14/16).
Java 8 update (3/19/14)
Because I'd assume this question will start popping up soon with the release yesterday: As of right now, there's no set date for when Android will support Java 8.
Here's a discussion over at /androiddev - http://www.reddit.com/r/androiddev/comments/22mh0r/does_android_have_any_plans_for_java_8/
If you really want lambda support, you can checkout Retrolambda - https://github.com/evant/gradle-retrolambda. I've never used it, but it seems fairly promising.
Another Update: Android added Java 7 support
Android now supports Java 7 (minus try-with-resource feature). You can read more about the Java 7 features here: https://stackoverflow.com/a/13550632/413254. If you're using gradle, you can add the following in your build.gradle:
android {
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
}
Older response
I'm using Java 7 with Android Studio without any problems (OS X - 10.8.4). You need to make sure you drop the project language level down to 6.0 though. See the screenshot below.
What tehawtness said below makes sense, too. If they're suggesting JDK 6, it makes sense to just go with JDK 6. Either way will be fine.
Update: See this SO post -- https://stackoverflow.com/a/9567402/413254
Normally, I would go with what the documentation says but if the instructor explicitly said to stick with JDK 6, I'd use JDK 6 because you would want your development environment to be as close as possible to the instructors. It would suck if you ran into an issue and having the thought in the back of your head that maybe it's because you're on JDK 7 that you're having the issue. Btw, I haven't touched Android recently but I personally never ran into issues when I was on JDK 7 but mind you, I only code Android apps casually.
Try not to use JDK versions higher than the ones supported. I've actually ran into a very ambiguous problem a few months ago.
I had a jar library of my own that I compiled with JDK 8, and I was using it in my assignment. It was giving me some kind of preDexDebug error every time I tried running it. Eventually after hours of trying to decipher the error logs I finally had an idea of what was wrong. I checked the system requirements, changed compilers from 8 to 7, and it worked. Looks like putting my jar into a library cost me a few hours rather than save it...
Android Studio now comes bundled with OpenJDK 8 . Legacy projects can still use JDK7 or JDK8
Reference:
https://developer.android.com/studio/releases/index.html
Just wondering if anyone has tried using new Java 7 language features with Android?
I know that Android reads the bytecode that Java spits out and turns it to dex. So I guess my question is can it understand the bytecode of Java 7?
If you are using Android Studio, the Java 7 language should be enabled automatically without any patches. Try-with-resource requires API Level 19+, and NIO 2.0 stuff are missing.
If you can't use Java 7 features, see #Nuno's answer on how to edit your build.gradle.
The following is for historical interest only.
A small part of Java 7 can certainly be used with Android (note: I have only tested on 4.1).
First of all, you could not use Eclipse's ADT because it is hard-coded that only Java compiler 1.5 and 1.6 are compliant. You could recompile ADT but I find there is no simple way to do that aside from recompiling the whole Android together.
But you don't need to use Eclipse. For instance, Android Studio 0.3.2, IntelliJ IDEA CE and other javac-based IDEs supports compiling to Android and you could set the compliance even up to Java 8 with:
File → Project Structure → Modules → (pick the module at the 2nd pane) → Language level → (choose "7.0 - Diamonds, ARM, multi-catch, etc.")
This only allows Java 7 language features, and you can hardly benefit from anything since a half of improvement also comes from the library. Features you could use are those which do not depend on the library:
Diamond operator (<>)
String switch
Multiple-catch (catch (Exc1 | Exc2 e))
Underscore in number literals (1_234_567)
Binary literals (0b1110111)
And these features cannot be used yet:
The try-with-resources statement — because it requires the non-existing interface "java.lang.AutoCloseable" (this can be used publicly in 4.4+)
The #SafeVarargs annotation — because "java.lang.SafeVarargs" does not exist
... "yet" :) It turns out that, although Android's library is targeting for 1.6, the Android source does contain interfaces like AutoCloseable and traditional interfaces like Closeable does inherit from AutoCloseable (SafeVarargs is really missing, though). We could confirm its existence via reflection. They are hidden simply because the Javadoc has the #hide tag, which caused the "android.jar" not to include them.
There is already as existing question How do I build the Android SDK with hidden and internal APIs available? on how to get those methods back. You just need to replace the existing "android.jar" reference of the current Platform with our customized one, then many of the Java 7 APIs will become available (the procedure is similar to that in Eclipse. Check Project Structure → SDKs.)
In additional to AutoCloseable, (only) the following Java 7 library features are also revealed:
Exception chaining constructors in ConcurrentModificationException, LinkageError and AssertionError
The static .compare() methods for primitives: Boolean.compare(), Byte.compare(), Short.compare(), Character.compare(), Integer.compare(), Long.compare().
Currency: .getAvailableCurrencies(), .getDisplayName() (but without .getNumericCode())
BitSet: .previousSetBit(), .previousClearBit(), .valueOf(), .toLongArray(), .toByteArray()
Collections: .emptyEnumeration(), .emptyIterator(), .emptyListIterator()
AutoCloseable
Throwable: .addSuppressed(), .getSuppressed(), and the 4-argument constructor
Character: .compare(), .isSurrogate(), .getName(), .highSurrogate(), .lowSurrogate(), .isBmpCodePoint() (but without .isAlphabetic() and .isIdeographic())
System: .lineSeparator() (undocumented?)
java.lang.reflect.Modifier: .classModifiers(), .constructorModifiers(), .fieldModifiers(), .interfaceModifiers(), .methodModifiers()
NetworkInterface: .getIndex(), .getByIndex()
InetSocketAddress: .getHostString()
InetAddress: .getLoopbackAddress()
Logger: .getGlobal()
ConcurrentLinkedDeque
AbstractQueuedSynchronizer: .hasQueuedPredecessors()
DeflaterOutputStream: the 3 constructors with "syncFlush".
Deflater: .NO_FLUSH, .SYNC_FLUSH, .FULL_FLUSH, .deflate() with 4 arguments
That's basically all. In particular, NIO 2.0 does not exist, and Arrays.asList is still not #SafeVarargs.
EDIT: At the time this was written, the latest release was Android 9 and Eclipse Indigo. Thing have changed since then.
Practical answer
Yes, I have tried. But this is not a great test as the compatibility was limited to level 6 with no way (no simple way at least) to really use java 7:
First I installed a JDK7 on a machine that had no other JDK installed - Eclipse and Android are not installed either:
Then I installed a brand new Eclipse Indigo and checked it was actually using the JDK 7 (well, as this is the only one and as this is the one I've selected I would have been surprised)
Then I installed the latest version of the Android SDK (EDIT: Honeycomb, API13, at the time this post was written). It found my JDK 7 and installed properly. The same for ADT.
But I had a surprise when trying to compile and run a Hello Word Android app. The compatibility was set to Java 6 with no way to force it to Java 7:
I tried with a non-Android project, a regular Java one, and I had the explanation. The compatibility level seems to be limited by Eclipse (see the message at bottom of the following image):
So I had Hello World working, and also other apps, more complicated and using SQLite, Listview, Sensor and Camera, but this only proves that the compatibility handling of Java 7 seems to be well done and working with Android.
So, did someone try with the good old Ant, to bypass the Eclipse limitation seen above?
Theroetical answer
Anyway, the SDK is designed to be used with Java 5 or 6, as explained here.
We may have something working with Java 7, but it would be working "by accident". The building of the DEX may work properly or not, and once the DEX built, it may work or not. This because using a non-qualified JDK gives unpredictable results by definition.
Even if someone has succesfully built an Android app under plain Java 7, this does not qualify the JDK. The same process applied to another application may fail, or the resulting application may have bugs tied to the use of that JDK. Not recommended.
For those who are involved on webapps development, this exactly the same as deploying a web application built under Java 5 or 6 under an application server qualified for Java 4 only (let's say Weblogic 8 for example). This may work, but this is not something that can be recommended for other purposes than trying.
Quote from dalvikvm.com:
dx, included in the Android SDK, transforms the Java Class files of Java classes compiled by a regular Java compiler into another class file format (the .dex format)
That means, the .java source file does not matter, it's only the .class bytecode.
As far as I know, only invokedynamic was added to the JVM bytecode in Java 7, the rest is compatible to Java 6. The Java language itself does not use invokedynamic. Other new features, like the switch statement using Strings or the multi-catch are just syntatic sugar and did not require byte code changes. For example, the multi-catch just copies the catch-block for each possible exception.
The only problem should be that the new classes introduced in Java 7 are missing in Android, like AutoCloseable, so I'm not sure if you can use the try-with-resources feature (somebody tried it?).
Any comments on that? Am I missing something?
As of the Android SDK v15, along with Eclipse 3.7.1, Java 7 is not supported for Android development. Setting the source compatibility to 1.7 mandates setting the generated .class file compatibility to 1.7, which leads to the following error by the Android compiler:
Android requires compiler compliance level 5.0 or 6.0. Found '1.7' instead. Please use Android Tools > Fix Project Properties.
To expand on the above answer by #KennyTM, if you are targeting 4.0.3 and above (minSdkVersion=15), you can use the hidden APIs by adding a few classes to your target's SDK android.jar.
Once you do this, you can use try-with-resources on any Closeable, as well as implement AutoCloseable in your own classes.
I've made a zip containing sources and binaries of all the classes that needed to be modified in android.jar to make these APIs available. You just need to unpack it and add the binaries to your android-sdk/platforms/android-NN/android.jar
You can download it from here: http://db.tt/kLxAYWbr
Also of note is that, in the past couple of months, Elliott Hughes has made a few commits to the Android tree: finished off AutoCloseable, added SafeVarargs, unhidden various APIs, fixed Throwable's protected constructor and added support for version 51 class files in dx. So, there is finally some progress going on.
Edit (April 2014):
With the release of SDK 19 it is no longer necessary to patch android.jar with the additional APIs.
The best method to use try-with-resources in Android Studio for an app that targets 4.0.3 and above (minSdkVersion=15) is add the following compileOptions to your build.gradle:
android {
compileSdkVersion 19
buildToolsVersion '19.0.3'
defaultConfig {
minSdkVersion 15
targetSdkVersion 19
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
}
Android Studio will complain that try-with-resources can't be used with this API level, but my experience is that it can. The project will build and run without issue on devices with 4.0.3 and above. I've experienced no issues with this, with an app that has been installed into 500k+ devices.
To ignore this warning, add the following to your lint.xml:
<issue id="NewApi">
<ignore regexp="Try-with-resources requires API level 19"/>
</issue>
It seems that getting this to work with pure ant is a bit of a kludge.
But it worked for me: http://www.informit.com/articles/article.aspx?p=1966024
In order to use Java 7 features in code build by Android's ant based build system, simply put the following in your custom_rules.xml in your projects root directory:
custom_rules.xml:
<project name="custom_android_rules">
<property name="java.target" value="1.7" />
<property name="java.source" value="1.7" />
</project>
Some people might be interested in this git project I've found, that seems to allow to run Java 7 on android.
https://github.com/yareally/Java7-on-Android
However too much of a risk if I add this in the current project I work on. So I'll wait until Google to officially support Java 7.