I have a android library with com.android.support:appcompat-v7:23.0.1 dependency in the gradle.
Say any applicaion with different version com.android.support:appcompat-v7:23.3.0is in the build.gradle of that application uses my library.
Below are the list of questions I have doubt.
which version does the android take? Lower one or Higher one? How do i see it?
Won't there be any conflict if i use different version like 24 or 25 and above or same?
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
which version does the android take? Lower one or Higher one? How do i see it?
Gradle uses the higher one.
You can use the command gradlew dependencies to check the dependencies tree.
Won't there be any conflict if i use different version like 24 or 25 and above or same?
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
In general the best way to maintain a library and to avoid the conflicts is to update the library always with the latest support libraries.
What if the compiledSDK of application is 23 with appcompat-v7:23.3.0 and and that of the library is 24 with appcompat-v7:24+. Which all support libraries does the android take?
If your library uses support libraries v24, the library and the app will require to be compiled with the same level = 24.
Related
The Android app I am working on is completely written in C++. I need to integrate it with a static library that also is written in C++. There is no dependency on STL in any of the projects.
The static library uses cmake to build. Unfortunately, the app is based on an old AOSP version of Android NDK and has no support for cmake.
I also have a newer version of Android NDK in a different directory. This version does support cmake toolchains.
I am thinking I will build the static library against the new NDK and use it in my main project. The ABI is the same for both the projects - armv7a.
I have tested this logic with a sample code. It seems to work. I am able to invoke methods in the static library from my main app.
Also, there are no name-mangling issues.
The question I have is if there is any issue I am overlooking.
I am thinking it should not matter that the compilers used to build the sources are different. As long as they are producing arm-compatible code, I should be able to able to integrate them.
As a matter of fact, another library that I am using, gstreamer, is available for download as pre-built binaries at https://gstreamer.freedesktop.org/data/pkg/android.
Please advice.
For those interested, mixing NDKs doesn't seem to be an issue as long as you follow certain guidelines. Some of them are listed at https://developer.android.com/ndk/guides/cpp-support.
Essentially, there is no problem if your project is 'C' based. However, if you are using C++, you must not use STL.
I have managed to build part of my code with two NDKs and I am not seeing any link time or runtime errors.
I am using Android Studio 3.0 with the updated gradle plugin.
I need to use the releaseImplementation keyword in my build.gradle file as I only want the library specified (ACRA) to be built in release. The reason I only want to build ACRA in release is that I've read that Android Studio instant run does not work well with ACRA.
releaseImplementation 'ch.acra:acra:4.9.2'
The problem is, however, that it's a library so I also need to use the api key so I can transitively export in apis to the modules using the library.
api 'ch.acra:acra:4.9.2'
Is it possible to use both keywords or is there a composite keyword to use?
releaseImplementation 'ch.acra:acra:4.9.2'
api 'ch.acra:acra:4.9.2'
In Android Studio 3.0 and newer, the Android Gradle Plugin supports the new Java Library plugin configurations that allow more granular control of dependencies.
As described here, the new Gradle Dependency configurations are available for flavor- or build-type-specific dependencies.
If you wish to use the api dependency configuration for the release build Type, you would add the following:
releaseApi 'ch.acra:acra:4.9.2'
This is the "composite keyword" that you are describing. No additional dependency needs to be specified.
I decided lately to move from Eclipse ADT to the latest AS version.
The first weird thing that I've noticed is that when I create a new project, it is always based on the Android support library even though I selected the minimum SDK to be level 19.
What is the reason for that?
Is there a way to configure it otherwise?
The reason for this is mainly backward compatibility. Right now, you may want to make your app for API19+, but later you may decide to lower it a bit down to support more devices, and you shouldn't be having problems with that, if you use support library.
There's also the thing that support library gets updated much more often than Android core library, therefore, if you base your project on it, it should be pretty much bug free.
One more thing, if you extend activity compat for example, the activity checks what version of Android you are currently having on your device and uses core features automatically if available, so it's good for you in many ways to use support library :)
I am trying to build a project using NDK media sdk, but I need it to run on older phones too (to support 90% of the market...). Now, I am able to include the libmediasdk.so & libOpenMAXAL.so manually, and it seem to link properly, but I am not sure this is a correct practice.
Moreover, the libraries (libmediasdk.so & libOpenMAXAL.so) are expected to be available on the target device, so unless I do copy them manually to the project/libs/arch-arm the application complains libraries are not found.
Have I gone too far ? :) hope not..
You can write code that optionally uses the new native media functions (libmediandk.so), but you can only use it on Android 21+. So if you want to support older android versions, you must make this codepath optional, allowing it to fail cleanly on other devices where libmediandk.so doesn't exist.
If the MediaCodec APIs are optional within your app and you are ok with them only being available on Android 21+, you can just make sure you build this into a separate lib (like libyourapp-media.so), and be ready to handle the case when System.loadLibrary() for this library fails.
However, if you want to use other native code components in your app, there's a few gotchas you need to know. If you build your app targeting android-21 and your native code uses certain functions (such as atof), it will only run on android-21 or newer (even if code using the function atof would build just fine for the older platforms). The reason for this is that the atof function didn't exist before, and calls to it were redirected to strtod. If you build your library targeting android-21, it will actually do the calls to atof instead, which doesn't exist in the older platform versions. This also goes for quite a number of other functions, not only atof. See http://b.android.com/73725 for details on this.
Therefore, if you want to use the new native media APIs in a library that should be loadable on older versions (except for the native media APIs that obviously won't work on older versions), you need to build your native components targeting an older android version. You'd need to duplicate the media/* headers from android-21, but instead of linking to libmediandk.so (-lmediandk in LOCAL_LDLIBS), you'd need to load this library at runtime using dlopen.
If you need to do the same on older platforms as well, you should use the MediaCodec API in java (which you can call via JNI). Then, there's little point in doing all of this extra work just to use the native version of the API on Android 21+, when you can use the java API on all versions (it works from Android 16, and more reliably since Android 18).
The docs on the ABS website seem slightly inconsistent.
On http://actionbarsherlock.com/usage.html it says
"Due to its use of the native action bar and its related classes on Ice Cream Sandwich, the library requires that both it and your project are compiled with Android 4.0 or newer."
This implies to me that it is okay to build both project and library with API 16.
However, on http://actionbarsherlock.com/faq.html it says "The library itself must be built against Android 4.0 (API level 14). Your project should be built using the latest version of the SDK as possible as long as it is 4.0 or newer."
This implies to me that API 16 is okay for the project, but the library should be built with API 14.
So, then, my question is, 16 or 14 for the library?
Thanks in advance, and thanks to Jake for writing and supporting ABS.
George
ActionBarSherlock is designed to make a decision on launch time:
Use the system's built-in ActionBar, etc. widgets and classes
Use ABS's compatibility ActionBar, etc. widgets and classes
It uses your build target to make that decision. If you target 4.0, then devices with 4.0 will use their built-in widgets and classes in your app. Devices with 4.1 and higher will do the same. Devices with any version below 4.0 (so, 3.2 and below) will use the compatibility ABS stuff.
Changing the target to 4.1 will make 4.0 use the compatibility ABS stuff, which is kind of unnecessary but not really harmful. But it's almost always better to just use what's on the device. So I'd recommend keeping it at 4.0.
Side note: 3.0 - 3.2 also have an ActionBar class, but it's missing a lot of features added in 4.0, so it's best to use ABS for those versions.