I have an Android library project. I include the version of the library in its manifest. I use this version internally, so right now I also have the version stored as a static constant. Is there any way to read the version of the library project from the manifest so I can remove this redundancy? From my searching, I'm guessing that the answer is no, since library project manifests are in essence discarded during the build process.
Related
How I can use com.android.setupwizardlib in my project?
This library isn't on jcenter or as gradle dependency.
This library is used in some apps (Such as Greenify) and it uses the XML tag com.android.setupwizardlib.SetupWizardLayout in my Activity
Any solutions about it?
I know how to import a library, I only need help with this specific google library
Greenify SetupWizardLib
It would be simpler for you to use existing packaged libraries for this functionality, such as some of these or a couple of these.
Otherwise, grab the source code and resources, add them to your project (directly or via a separate library module), and make changes as needed to get it to build.
Which is the right place to specify android's library project version code/name? Whats the current state on a library's Android Manifest? When you bundle a library jar, can AndroidManifest be ignored while bundling jar and still delivering a usable/unbroken jar?
My question is related with this
You set version code/ name of a project in its AndroidManifest.xml. But if it's a library project, all information in the manifest will be ignored after integrating into the host project.
There is an issue.
BuildConfig.VERSION_NAME
BuildConfig.VERSION_CODE
Just make sure that you import the BuildConfig for your library (as literally every android library/app has it's own BuildConfig on it's package path). The Android Studio's Gradle Build system indicates that this is always generated as of version 0.7.0 (see changelog). This persists as a generated class into the hosting app/library.
I've created apk by maven + eclipse.
It is a single file and has internal references to libraries given by mvn dependencies. On my android everything works great, but I need to display in runtime version of referenced libs. I know how to display version of my application (from androidManifest.xml), but the problem is to get version of other used library, which in some way is included to my apk.
Inside apk I don't see my referenced jars, I suppose it is made by class.dex.
I found the way to get version from jar lib, but it doesn't work for apk.
Can we found version of internal reference library at run-time?
Let me rephrase your question.
You have developed a mobile app which uses third party library and your goal is to find the version of that third party library from APK.
If i have understood it correctly,
then i faced a similar requirement recently.
Firstly the third party jar's manifest will have version information.
When you built APK this manifest info that contains the version info wont be merged with APK's AndroidManifest file.
AndroidManifest schema does not seem to provide this facility.
In our case we ship the library ,so one probable solution is that we can probably add the version info into metadata element inside activity element in Android Manifest file of the library so that apk when it is built it will copy the activity element from the library's android manifest to the app's android manifest.This way we can pass that version info of a library to main APK's Android Manifest.
May be we can make a request to modify the schema of Android manifest to give provision to include version info of internal library.
Please check the following link.
https://developer.android.com/guide/topics/manifest/manifest-element.html
The other solution could be one can possibly use jarsigner to insert custom entry (that contains info on version of third party library into APK's manifest file after building APK.
Thats again not a standard solution.
One of the newer functions of Android is the ability to create a Library Project.
This is great for unit testing and sharing common functionality across many apps you may be developing, but I seem to have stumbled upon a bug in their implementation.
When you have the following situation:
-LibraryProject contains LibraryProject/libs/folder/lib.jar in it's build path.
-ReferencingProject references LibraryProject.
From ReferencingProject you don't have access to anything inside lib.jar (Such as constant's used to communicate with methods in the Library Project).
A solution to this is to include "lib.jar" as an external library in the referencing project but this approach begins to negate the benefits you gain from having a self contained Library Project by creating multiple manually added references to resources which could move/change during the development of the library project (not to mention cause some pretty confusing errors).
Is there any way to expose an included libs classes to the referencing project without having to manually reference them as external jars?
As #Selvin says,
In the Library Project you can specify which libraries you want to mark as "exported" in the window brought up by using: Project properties => Java Build Path => Order and Export. From this example you would check libs/folder/lib.jar.
Clean and build the Library Project and the "exported" libraries are now included in the produced jar.
EDIT
This is a symptom of upgrading to ADT 17 - (Android Team: Perhaps put a few warnings on your release notes when an update breaks existing architectures?)
http://tools.android.com/recent/dealingwithdependenciesinandroidprojects
If you don't want to add the library to the "Order and Export" then placing local jar's in /libs/ base folder will automatically add it to "Android Dependencies" which are exported in the jar created from your shared library.
EDIT2
Recent ADT upgrade would have you also manually select "Android Dependencies" as "Exported" in your Java Build Path. Again, warning would be nice.
I've read similar questions here, but am still not clear on a couple of things. Using a Library Project means that my overall project will have two manifests -- one for the library and the other for the "main" app project -- and I'm not clear what goes in which or if there is some redundancy.
I'm developing an app widget with "lite" and "paid" versions, so will have almost all code in a library project. Being a widget, the library will have at least a receiver, a service, a configuration activity, plus a couple of other activities. So where should the full declarations of these components -- including intents, filters, etc. -- be declared? Do they go in the manifest for the library, or in the manifest for the application package itself, referencing the classes in the library (e.g. android:name="com.foo.mylibrary.MyService")?
Some examples I've looked at seem to declare them in both manifests, but I suspect that putting these in one or the other is a no-op.
Using a Library Project means that my overall project will have two manifests -- one for the library and the other for the "main" app project -- and I'm not clear what goes in which or if there is some redundancy.
The library project manifest is not presently used.
Gradle for Android, and therefore Android Studio, support library projects and AARs publishing a manifest. This can include things like activity declarations, required permissions or features, or minimum supported Android SDK levels.
The rules for how library manifests are merged with the app's own manifest -- particularly when you take build types and product flavors into account -- is a bit complex.
So where should the full declarations of these components -- including intents, filters, etc. -- be declared?
In the host project.
The library could publish those components, and the Android Studio host project can then remove them if needed.
Do they go in the manifest for the library, or in the manifest for the application package itself, referencing the classes in the library (e.g. android:name="com.foo.mylibrary.MyService")?
The latter.
In either (with Gradle for Android and Android Studio). In theory, it is easier for the library to publish the components, so the app author does not have to. Personally, I am not a huge fan of this, as too many developers will wind up shipping unnecessary manifest entries.
As of ADT r20 Preview 3 it is now possible to merge manifests. So common configuration can now be put into the library manifest. See https://stackoverflow.com/a/10400355/262789 for more information.
Version 13 of Intellij IDEA is necessary for manifest merging support (manifestmerger.enabled=true). Also the Grade based build system appears to be necessary for Android Studio support.
Any referenced android elements like activities, receivers, services, etc. MUST go into your Application manifest or they won't be recognized by the OS. As you guessed, the Library manifest file is pretty much an empty implementation
UPDATE
As CommonsWare points out above, the Android build tools will now attempt to merge the various manifests on your behalf. Leaving up the original answer for posterity