Does JRE 1.7 work with all api levels of android?
I want to make an app by this situation:
<uses-sdk
android:minSdkVersion = "7"
android:targetSdkVersion = "19" />
Is this ok with jre 1.7 ? or do I need to use jre 1.6.
How can I figure this out which API level with which JRE version is compatible ?
The core Java libraries are part of the Android runtime(see image below) layer, but from developer point of view it doesn't matter. What you can do and cannot do is tied to Android SDK level you use in your project.
Which android:minSdkVersion you should use?
You can check the Android documentation. For every instruction /
command / method / properties, at the top right you'll find the API
level at which you are able to access said property. Clicking on the
API level will take you to a page which contains a table that
translates API level to Android versions.
As a general principle set android:minSdkVersion as low as possible. You will get a compiler error when you use something not supported by that level. This way you can support as many users as you can. See this for details.
Here is a recommended reading on this subject.
Android API level is specific to which version you are using(as in ICS, Kitkat etc). What JRE you use is independent thing.
But is it better you use the most recent JRE i.e Java 7 irrespective of what your API level target is.
It may happen that the recent API levels may use some java functions introduced in recent java versions. So again irrespective of your target API level use Java 7.
See this SO answer for more info.
Related
I know there are a lot of questions on here about Android API Level and Version but this question is different so please don't mark it as a duplicate.
I am wondering how Java version 1.6, 1.7, 1.8... relates to those two. The source of my confusion is me trying to use the Pattern.compile method with the Pattern.UNICODE_CHARACTER_CLASS flag as seen below.
Pattern pattern = Pattern.compile("\\b" + keywordToCheck + "\\b", Pattern.UNICODE_CHARACTER_CLASS);
From the docs on Pattern.UNICODE_CHARACTER_CLASS it says that it says Since: 1.7, which I assume to mean it is available in Java version 1.7 and above. I am trying to use that line of code in an Android project but every time I run it on my device I get:
java.lang.IllegalArgumentException: Unsupported flags: 256
Below are the relevant parts of my build.gradle file
defaultConfig {
minSdkVersion 19
targetSdkVersion 26
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
From my understanding this means my app will use any API level 19 and above, which means it can run on Android 4.4 (KitKat) or higher. The device I'm running the app on has Android 6.0. How does the Java version fit into this? I am using Android Studio 3.0 which says I'm using:
Android Studio 3.0
Build #AI-171.4408382, built on October 20, 2017
JRE: 1.8.0_152-release-915-b08 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.6
Can someone explain to me why I'm getting this error, and also the relationship between Android API Level, Version, and Java version? Thank you
In the case of your given example, that flag wasn't added until API 24. In a lot of cases, even though support for a given language level (e.g. 7) was added earlier doesn't mean everything is added instantly. Some things are waited with for whatever reason Google has for waiting with it.
I can't tell you why because I don't know.
And as Gabe mentioned, the versions of Java isn't necessarily compatible with Android.
So because of your code where you use the flag on API 19 and up, you'll get a crash on versions between and equal to 19 and 23 because the flag isn't added yet.
And it's also worth noting that version compatibility doesn't limit versions of Java by versions of Android. Now you can for an instance run Java 8 on whatever version of Android you want. This is compatibility.
However. If you read Android Java 8 Language Features, it says (emphasis mine):
Android Studio 3.0 and later supports all Java 7 language features and a subset of Java 8 language features that vary by platform version.
I'm using Java 8 as the example here, but this applies to mostly every version of Android and java.
Essentially:
The flag you're using wasn't added until API 24. AFAIK, usage wasn't added even though the hard-coded variable is there
Android doesn't necessarily have every single Java API, and these vary by versions of Android
Versions of Java isn't limited by API, but the accessible features vary. Meaning you can run Java 8 on API (random number) 12 if you wanted to.
There's no fixed relationship (Android [x] = Java[x]) between the two. Different fields/methods/classes may be added eventually, instantly (on release of support for a given version of java) or not at all.
The regular Java and the version of Java used in Android are two very different ones, because Android is platform-based while Java is version-based. You can't compare versions between them, and they both have separate documentations.
It's worth noting that for Android (Java) questions you should look at the Android docs which can be found in the API reference instead of using the Oracle documentation which doesn't apply to Android because of the massive differences in the API.
When it says available since 1.7, notice who's docs you're looking at- the Oracle (official Java docs). So it will always be Java version. Android documentation will always give you the Android SDK version its available since.
Note that Android is not always 100% compatible with Java's official versions. It tries to be, but obviously large chunks of the library just aren't there. When in doubt look at the Android documentation of the class, not the Oracle.
As for Java versions- they're independent from Android versions, mostly. Java 8 was just made officially fully supported with AS3. Before that it was deemed experimental. You can still use Java 7 if you want. For Java 8, most language features are available on all platforms, but one or two require a minimum SDK version of 24. The two I know of like that are Java streams and Annotation types/repeated annotations.
For your specific problem, note the android documentation says this about the flag: "This flag has no effect on Android, unicode character classes are always used." So you can just remove it.
I need to integrate some code with extensive usage of Java lambda functions.
Several restrictions I have demand that I develop my project using Eclipse Mars, with the latest ADT plugin, and not Android Studio.
The problem is that using Lambda functions demands using 1.8 JDK compliance, but if set so, I get this message:
Android requires compiler compliance level 5.0 or 6.0. Found '1.8' instead.
How can the two live together in harmony?
Edit:
This is not a a duplicate of the questions suggested, as I'm asking about ADT Eclipse, and since the last update in that question, Android does support Java 8, so no only is this not a duplicate, but that question is now (after 1.5 yrs after the last update) obsolete.
Update on Java 8 language features on Android
Lambda is back ported to older versions of Android.
This is a feature from Android Gradle Plugin 3.0 and above, lambda is back ported to older Android OS versions as part of other Java 8 language features.
Add this to your Gradle build scripts to enable the feature.
android {
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}
For more details, see Use Java 8 language features, and Android' Java 8 support.
As #dhke said, there's no support for Java 8 on Android yet.
Use Java 8, Build For Java 6/7
But you can still use JDK 8 to develop Android application. You just need to set source compatibility to either 6 or 7 depends on your minSDKVersion. Thus, you would lose any new features introduced in Java 8, like lambda in your case.
Backport of Lamda
Since you have extensive usage of lambda, Retrolambda might be an option for you. It provides backport of lambda for pre-Java 8 versions. It has Maven/Gradle/command line plugin to enable the support.
Other Backports
If you need other Java 8 features, AFAIK, ThreeTen ABP provides backport support for Java 8 Date Time API.
You cannot currently (as up to at least Android 5.1.1) use lambda functions on Android.
Lambda functions require new Dalvik (not necessarily JVM!) opcodes (liberate-variable, box-lambda, unbox-lambda, capture-variable, create-lambda, invoke-lambda) that neither Dalvik nor ART currently have support for.
It looks like google might have scheduled (though nothing seems to be official yet) Java 8 support for post 5.1.1 (API Level 23 and later). At least the smali disassembler already added support with a distinct reference to the API level:
https://github.com/JesusFreke/smali/commit/144951a9e9e6c87866245f2bdeebf0ebedaa0e38:
Add new -X/--experimental flag to [dis]assemble opcodes not in art yet
Add new opcodes liberate-variable, box-lambda, unbox-lambda, capture-variable, create-lambda, invoke-lambda
Add support for encoding 25x instructions
Adds LambdaTest to check new opcodes assemble/disassemble properly
And also
https://github.com/JesusFreke/smali/commit/144951a9e9e6c87866245f2bdeebf0ebedaa0e38#diff-5d7892344c0b747d3667bf8623c690c5R66
options.apiLevel = 23; // since we need at least level 23 for lambda opcodes
This only marks the opcodes, not the necessary library changes. It also does not tell us anything about Android itself, so I'd suggest not to take this as an official release schedule.
Android does support Java 8, so no only is this not a duplicate
As of Android N preview release Android support limited features of Java 8 see Java 8 Language Features
To start using these features, you need to download and set up Android
Studio 2.1 and the Android N Preview SDK, which includes the
required Jack toolchain and updated Android Plugin for Gradle. If you
haven't yet installed the Android N Preview SDK, see Set Up to Develop
for Android N.
Supported Java 8 Language Features and APIs
Android does not currently support all Java 8 language features.
However, the following features are now available when developing apps
targeting the Android N Preview:
Default and static interface methods
Lambda expressions
Repeatable annotations
There are some additional Java 8 features which Android support, you can see complete detail from Java 8 Language Features
I don't think this is going to work.
In order to use lambdas, you need source compatibility level 1.8. In order for the DEX compiler to work you need target compatibility 1.7. Eclipse is not going to let you set the target compatibility below the source compatibility (picture below).
Note that this is unrelated to IntelliJ's habit of thinking it knows way better than you do, what your code should look like. It can show you a lambda, even when the actual code is an anonymous class.
UPDATE: Since a few days, Android Studio 3.0 is out on stable. It officially supports a subset of Java 8 features, lambda expressions among them.
According to this Android Developers Blogpost from March 14th, 2017, google
decided to add support for Java 8 language features directly into the current javac and dx set of tools, and deprecate the Jack toolchain. With this new direction, existing tools and plugins dependent on the Java class file format should continue to work. Moving forward, Java 8 language features will be natively supported by the Android build system. We're aiming to launch this as part of Android Studio in the coming weeks, and we wanted to share this decision early with you.
So we probably won't have to wait much longer for Java 8 in Android Studio.
Reverse The Lambda Syntax
As far as I know, everything done in the new Java 8 Lambda syntax can be done using old-school Java code such as anonymous inner class. (Oracel Tutorial) (Oracle Quick Start)
To ease the burden of undoing the Lambda syntax, some IDEs such as NetBeans can suggest automatic revision of code in either direction to/from Lambda syntax. With one-click of approval, the syntax is auto-magically swapped. See the NetBeans document on Using Lambda Expressions Support.
Here is a screenshot of NetBeans offering to turn a Vaadin button’s Button.ClickListener from Lambda syntax to an anonymous inner class. Notice the mouse pointer clicking on the light bulb icon on line # 107.
To enable this feature in your IDE, you will need to enable Java 8 in your project temporarily. After undoing all the Lambda syntax, switch your project back to Java 6/7. In NetBeans the way to enable Java 8 is in your project > Properties > Sources > Source/Binary Format (popup menu) > 1.8.
I was wondering if I can use default methods in interfaces in Android development.
The feature is included in Java 8, but I have found out that Android Java VM doesn't yet support it.
It there any way to use default methods in Android development? If not, when this feature will be available, is there some kind of timeline for this features?
On the availability: I think we'll see default methods in Android N. There are already a lot of tests related to default methods for the new Jack compiler on AOSP. See http://bit.ly/1PZoV1A
And today the java.util.function package has been merged into the ojluni master (including default methods and the use of lambdas).
Edit: Here is the official confirmation that Android N is going to support Java 8: http://developer.android.com/preview/j8-jack.html
Streams are still missing but java.util.Spliterator(s) has been integrated yesterday. Given the current pace, I'd expect we'll see the Stream API in May.
Possible duplicate : will android java support lambda expression in java 8?
In the possible duplicate question, kapep answered this (read the full answer for more details) :
Android doesn't use Oracle's Java SE versions, it's based on parts of the Apache Harmony project so it doesn't even support Java 7. Harmony is not actively developed any more and won't support 1.7.
So I think you can forget new features of Oracle Java version for Android development and follow the Android API (not the Oracle one).
I am writing an Android app which needs to be run on BlackBerry Z10, too. Someone mentioned that Android apps can be wrapped for BB. However I am not sure of the version. If I use 4.x specific features, e.g. swipeable tabs, will they be supported on BB, or should I use some older API, e.g. Eclair (2.1) to be on the safe side?
I just want to program once, and not twice.
Today, you should build your Android apps to OS version 2.3.3 (API level 10). So, you should produce a version of your app that doesn't use features in newer API levels.
Here is the official BlackBerry page that mentions this:
You can use the BlackBerry Runtime for Android apps to run Android
2.3.3 platform applications on the BlackBerry Tablet OS and BlackBerry 10. To use the runtime, you must first repackage your Android applications to BAR file format, which is the compatible file format
required for an application to run on the BlackBerry Tablet OS and
BlackBerry 10.
Update: it appears that BlackBerry has a status page here, detailing their roadmap for Jelly Bean support. Of course, every device won't support it the day it comes out, and BlackBerry has missed deadlines before. But, it's probably good to keep all those things in mind when planning your project.
The right decision for you will depend on how long you expect your development to take (2 weeks, 3 months?), how important the features are that depend on 4.x APIs, how much you're willing to assume BlackBerry meets their schedule, and how important a strong launch is to you. If only a small number of devices are actually upgraded to support Jelly Bean when you release, it may hurt your sales.
Anyway, the point is that it depends on a lot of factors. Hopefully, I've described most of the important ones.
I would suggest 4.2. This is because in June, next month, the platform will be updated to support 4.2 from 2.3.3. By the time you get round to publishing you shall be all set.
After installing the Android SDK, I noticed that I need to choose the platform, i.e. Android 1.3 all the way upto 4.1 individually.
My question is, does this mean if I create an app, I have to create it on each and every platform individually?
I am a total noobie to Android development...
It's basically recommended to choose lowest API you plan to support in your application (unless you know you got reasons to have it set differently). For example if your app is for Honeycomb and newer versions only, then select SDK 3.0 to get access to all the features newly introduced in HC which you may want to use. But if your application shall run also on older devices with older versions of Android like 2.0.1 (or even 1.6 if you really need) set this to lowest API desired. So, now that rule is sufficient for you and lets you ensure you accidentally won't use any API method not supported on all platforms you target to which would lead your application to crash.
If not sure what API you want I suggest go for 2.x and simply ignore any older Android versions as it is basically pointless, according to platform version breakdown statistics published by Google.
I recommend you read this SDK article on how to define minSdk and targetSdk elements to match your requirements.
Take a look here
Basically it means that your app is meant to be used with this android version (but you can support higher or lower version too).
I strongly encourage you to read the documentation to understand better how the all thing works.
A simple answer is no.
When you are developing an application you have the provision to specify which is the minimum platform that you are developing for. The newer SDk will have more features which might not be available in old ones so care must be taken to see that your app is available for a specific platform.
I would suggest that you bookmark the developer.android.com and stakoverflow.com websites, they will be very handy :)
No. You can specify a minimumsdkversion for your app in your Android Manifest, so that it will support all the platforms from this API Level up to the newest platform.
See here for more information.
Edit:Of course you can't use some newer API functions in older SDKs, without the support lib, or some third party libraries(e.g the actionbar, fragments, expandable notifications etc.)