Android studio will show you if there is a newer version of a library when the version number is hard coded. But if you use variables, this seems to short circuit that functionality. Is there any way to get it back? I want to see available updates in build.gradle without having to Inspect the project.
Gradle 6 offers a new way to recommend and share versions between projects called platforms. This allows you to specify a set of dependency versions to share across projects without using variables.
You can use the Java Platform Plug-in to create a platform; a special kind of project that only contains a list of dependencies that work together. I haven't tried this, but hopefully Android studio will alert you if any of these versions are out of date since you'll be using hard coded version numbers.
You can then reference your platform in your other projects using the platform keyword and load all the other dependencies without versions
dependencies {
// get recommended versions from the platform project
api(platform(project(":platform")))
// no version required
api("commons-httpclient:commons-httpclient")
}
Related
Im investigating Android Room databases in my current application.
I am trying to install the most recent version of Sqlite by employing the most recent aar
I have tried placing the aar in my database module libs folder and referencing that in my gradle file however the sqlite version displayed is always 3.22.0
where the aar is 3.34.0
what are the steps I need to follow to override the version of Sqlite supplied by default and use my downloaded aar file?
or
Is this not possible?
The sqlite.org website has this
There are three ways to add the SQLite Android bindings to an
application:
By adding a pre-built aar file to the applications Android Studio
project. By building an aar file, then adding it to the applications
Android Studio project as in (1). By adding the SQLite Android
bindings source code to and building it along with the other
application code. By default, the SQLite Android bindings support
Android API levels 16 and greater (Android versions 4.1 and up). There
is also a separate version that supports Android API levels 9 and
greater (Android version 2.3 and up). Please note the extra step
involved in obtaining the code if you wish to use the version
compatible with API level 9.
Using a Pre-Built aar File This is the most straightforward option. An "aar" file is similar to a jar file, except that it may contain
both compiled java classes and native code. An aar file for the latest
SQLite release usable with API levels 16 and up is available from this
page.
There are two steps involved in adding an aar file to an Android
Studio project:
Import the module. In Android Studio 2.1 this is accomplished by
selecting the "File" -> "New" -> "New Module..." menu and then
choosing "Import JAR/AAR Package". Add a dependency on the new module
to the main application module (or to all modules that will use the
SQLite Android bindings). In Android Studio 2.1 the dependency may be
created using the project structure dialog (select "File" -> "Project
Structure...") or by adding code similar to the following to the
application modules build.gradle file:
dependencies {
// Change "sqlite-android-3130000" to the name of the new module!
compile project(':sqlite-android-3130000')
}
I've tried this approach and room still reports the original version.
I believe there is an approach that will replace the bundled sqlite that is provided by Android as default
To use a different database implementation with Room, you need to find (or create) a SupportSQLiteOpenHelper.Factory implementation and supply it to your RoomDatabase.Builder via openHelperFactory():
val builder = Room.databaseBuilder(context, SomeDatabase.class, DB_NAME)
.openHelperFactory(factory)
.build()
The simplest way to do that is to use Requery's standalone SQLite library. You would use RequerySQLiteOpenHelperFactory as the implementation of the SupportSQLiteOpenHelper.Factory, and it will use Requery's packaged copy of SQLite instead of the framework one.
If, for some reason, you do not wish to use Requery's library, you would need to find an equivalent that you like, or you would need to implement the SupportSQLite* APIs yourself. I did that twice for SQLCipher for Android, and it is a pain, but it certainly is doable.
SQLite comes bundled with the Android SDK, that means that SQLite version is changing with the increasing of the API level. Phone manufacturers can choose to ship different sqlite version with their device system.
Final verdict, you can't change it, unless running on rooted device.
Edit: Guide suggests using different sqlite version to by-pass the built-in, that would require usage of different wrapper around the new sqlite which will not communicate with the system one. This prevents you from using android database packages, including Room.
When investigating technology for data persistence in your android project, JPA for android should be considered. JPA is java standard, and JPA code can be re-used on java server side or other java client. see Cmobilecom-JPA for android.
As the title mentions, I am using buildSrc and Kotlin for Gradle Dependency management in a modularized android project as per the following tutorial:
https://caster.io/lessons/gradle-dependency-management-using-kotlin-and-buildsrc-for-buildgradle-autocomplete-in-android-studio
it's working all fine but the question is how can I be notified if there are any libraries that have an update on their version? (i am not getting the notification on the library where it gets marked showing that there is an update)
is there another way of doing this?
There are a few approaches you can take here:
Leave out the dependencies in build.gradle. Currently, there is no hint shown in Android Studio if you extract out them into variables. So you can just use strings here.
Use Gradle-versions-plugin to check for dependency updates. You can read more about this here.
I have a game that I am working on that uses the LibGDX game framework. Currently the platforms I am targeting are Desktop (PC, Mac, Linux) via a platform independent jar and Android.
The project is hosted at https://github.com/NoxHarmonium/project-whiplash Feel free to take a look if you need to.
The bulk of the code is in a module called core and is written entirely in Kotlin. This module is linked into both the Desktop and Android projects.
This works fine for Android versions 7.1+ and for desktop. For all other versions of Android I get a pile of java.lang.NoClassDefFoundError exceptions on anonymous functions such as this:
val objectObservable = this.observableCache.computeIfAbsent(assetRef, fun(assetRef: AssetRef): Observable<T> {
return Async.start(fun(): T {
...
}).observeOn(this.eventLoopScheduler)
})
Exception Sample:
java.lang.NoClassDefFoundError: com.projectwhiplash.utils.assets.LibGdxDataManager$objectMapFromYaml$objectMapObservable$1
It seems to be caused by an incompatibility with the JVM that Kotlin targets by default (1.8) and the JVM level that older versions of Android support (1.6). I could be wrong but this explains why the latest version of Android works as it supports a later version of the JVM.
The solution should be as simple as forcing Kotlin to emit JVM byte code as version 1.6 but I can't seem to work it out. If you compile Kotlin directly into an Android, this seems to be handled by using the kotlin-android Gradle plugin. Unfortunately I can't use this plugin for the core module because it should not have any Android dependencies.
I tried to override the JVM version using the build settings mentioned at https://kotlinlang.org/docs/reference/using-gradle.html#compiler-options like this:
compileKotlin {
kotlinOptions {
jvmTarget = "1.6"
}
}
However, it did not seem to work no matter which Gradle file I placed it in. In fact I get a "Cannot resolve symbol 'kotlinOptions'" error shown by Intellij when I try it. It is possible that the Kotlin team have changed something and the documentation has not been updated.
I can override the Kotlin settings manually in the Intellij module settings but it gets overridden every time I sync the gradle project and is not a good long term solution. The project is designed to be IDE independent.
Does anyone know how I could set up the core module for max compatibility with older versions of Android?
I currently have the minimum API level set to 9 as this is the current LibGDX default but I'm willing to set this higher if it would be too difficult to target such a low API level.
Edit 1:
I just extracted the jar file produced by the core module and examined the class files using the javap tool.
I ran the following command on a random class file
java -verbose foo.class
and it output text with the following text
...
minor version: 0
major version: 50
...
using this question List of Java class file format major version numbers? I determined that the class file is actually targeting JVM 1.6.
Therefore my original theory is wrong and there is another reason why older Android versions cannot load classes generated by Kotlin lambdas.
It looks like you are using functionality that only exists within the JDK 8 library. Specifically the computeIfAbsent() method on the Map class.
Because of this, even though your code has been compiled down to JVM 1.6 compatibility, the underlying implementation on Android devices is missing that functionality and thus the reason for the NoClassDefFoundError exception you were seeing.
Updated: You can see in the javadoc located at https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#computeIfAbsent-K-java.util.function.Function- that the computeIfAbsent() has only been around since JDK 8
I have created a library in Android Studio and wanted to give it to someone for testing.Besides maintaining it in the svn I am providing the version of the library hardcoded in the Library code which I keep on changing everytime I build and send it for testing to track the record.
The code is as below :
defaultConfig {
..
..
..
versionName "0.00.0012"
}
and then getting the version of the Library as BuildConfig.VERSION_NAME
Does the App version will change in the AndroidManifest.xml as well automatically?
is there any other way of managing the various lib versions?
android:versionName="not the same version"
Does the App version will change in the AndroidManifest.xml as well automatically?
No, library version will not influence application's version in any way. Both are separate.
is there any other way of managing the various lib versions?
What you do lets the consumer check the version of the library in code, which is fine. If you want to actually distribute new versions of the library then you'd probably want to use a maven repository - either local or a remote one, and push your library there with given version. This is the version you then reference in compile 'com.my.library:library:1.2.3'.
I am using compile 'com.localytics.android:library:3.8+' in my project.
I want to know that is the latest version of this dependency is picked when the release apk is created or every time when the user opens the app (downloaded from playstore).
You should avoid the use of the + in your dependencies.
In this way you will not be able to replicate your build in the future because you can't know the versions used in your app.
Dynamic versions add nondeterminism to your build and can introduce unexpected behavior changes to your app.
To check Newer Library Versions Available you can use a lint check:
Go to Settings > Editor > Inspections > "Newer Library Versions Available"
Enable the Newer Library Versions Available inspection
Go to Analyze > "Run Inspection By Name" and search for Newer Library Versions Available
You will launch a link check
new version downloads when You create a new build. There is nothing changes in it before You create a new one.
+ here known as dynamic dependencies.
Simply + will use the latest or updated dependency but Using dynamic dependencies (for example, com.localytics.android:library:3.8+) can cause unexpected version updates and regression incompatibilities as suggested by google docs
Pros
Stay updated
Manually updating dependencies can be tedious
Cons
Can break your current code flow due to changes in lib code
Usually there can be some bug found in the new releases so be ready to face unexpected behavior or crash
Conclusion : As advised by google always specify the library version check under Adding Support Libraries