I am turning an project that I have been working on for while into a library project and I would like to know what can be left out of that project.
The library is only source code (no images or UI). What can be left out of the ManiFest.xml file, and can I safely remove all the drawable, values, layout, and layout folders? I know I will no be using those resources, and strings resources will be handled by the referencing project.
You can remove anything that is not directly referenced by your library project. It just has to be a viable Android project that compiles.
Pretty sure you can have a bare bones manifest file too. Since you cannot run a library project and you have to copy the anything that would be declared (e.g. activities, permissions, services, content providers etc) into the manifest that uses your library project anyway.
I started working with Android Library Project since r12, If I were you, I would highly consider waiting a little bit longer (until r17 release).
Android dev team started revamp the whole Library Project design during several recent release (probably since r14), and promise us a ultimate solution in next coming release. check out this blog for details. This leaves our continuous development in an extremely unstable stage at the moment, there are already numbers of threads posted on the internet, for example, this one complain about the compatibly with legacy Library Project, regardless of whether you use Ant, Maven or purely ADT manage your Library Project. From my own experience, I use Maven manage my Android Project, each time I upgrade my SDK since r14, Library Project is always the trouble maker. I would expect another tough landing when upgrade to r17, hopefully the last time.
If you insist, these are some development considerations you may need aware.
Hope this helps.
Related
I'm not too familiar with the Android build process, so I'm sorry if this comes off as a really stupid question.
Anyway, I'm writing testing code utilizing ActivityInstrumentationTestCase2 and Robotium for an Android application by the company I work for.
The company is rather large, so the transition to Gradle is going very slow. I would like to use Gradle for my testing project for ease and future maintainability, but right now the application I'm testing is built using a combination of ANT scripts and manual intervention with all dependencies checked in as jars in the repository. I'm not at all involved in that process, but I know it's pretty hacked together.
From what I understand, Gradle cannot simply depend on and trigger the building of another existing Android project unless that project also utilizes Gradle. So unless I want to really get my hands dirty with the build process of our application (we have people who are literally hired to only deal with that), I'm out of luck.
What I do have access to, however, are debug builds of our application.
So my question is, is there some way that I can have Gradle use the compiled debug APK as a local file dependency, or can APKs not work like that?
APKs don't work like that; you can't depend on them, for a variety of reasons. The most important reason is that the code and resources are processed and compressed and much of the original information needed to build them is lost at that point.
You'll have a tough time getting it to work properly. If things that you depend on are pure Java libraries, then if you could get them in JAR format you could depend on them from a Gradle project pretty easily. But if they're Android projects containing resources and manifest entries and such, then there isn't a compiled file format you could obtain those libraries in that would be compatible with Gradle. Gradle supports the AAR format for Android libraries, but that format is generated by Gradle and nothing else.
Well I want to highlight this and bring it all in this thread, as the rest of threads did not have a concluded answer, so before skipping into them here are the threads I referred to:
Adt doesn't create default hello world but command line does
[solved ]Eclipse behaving differently while creating new project/activity
ADT has been behaving a bit weird since past few days. I keep my SDK always updated so I frequently Run the SDK manager and download all the updates. recently I noticed that if I create a new android app project it is not creating a default MainActivity even if I check that box, it does not create a Activity under src and more to annoy me, I wasnt able to refactor anything, so I realized that I had to update my Eclipse as after reading few posts, but now when I create every new project it creates an annoying appcompat_v7 project with EVERY project, say I create two new projects it creates appcompat_v7_2....this is driving me crazy and the new project library is the appcompat_v7 project. This is becoming annoying and no idea whats going on here !!!! What should I do...please rescue me ! Thanks in advance ....A screenshot to annoy u guys too ... :)
***************Current Alternative, not a solution***********************
As of 12/5/2014 with ADT 23.0.2 I dont see this issue anymore.
I have waited for an acceptable solution on this issue (as of now there is none), but one of the SO members directed me to this post https://code.google.com/p/android/issues/detail?id=66975. What I am doing is described in one of the solutions below, but for people who have come to this post, the alternative is to delete that ugly project(if you have more than one) which has been created and add up this one(appcompat_v7) as a library. So if you create another project and appcomat_v7_2...comes up delete that and point your project to the appcompat_v7, do the same for other projects too. This is not recommended for some reason though, but it worked well for me till now without issues. If anyone hits up with a solution please post it here.
****************Current Alternative, not a solution*****************************
the folder appcompat_v7 doesnt get created if i use
minSdkVersion="14"
Seems like it is a eclipse bug. What you need to do is go to properties in the of the Android Project and in the Android Section. Add the library appcompat_v7 and remove the appcompat_v_7_2 (duplicate). Then you can remove the appcompat_v7_2 as a eclipse project. All errors fixed.
Just a workaround.
The appcompat project is a library to support android's older versions. The support library was introduced by Google recently - I don´t know in which Android version.
But the point is, this project is only created when you create an Android project to cross Android platforms. I mean, when you select an old min API, e.g. API 8 (Froyo), but target recently versions, your project must have the support library.
Anyway, the creation of appcompat_v7 project is some issue that has to be better configured by the eclipse plugin maintainers. However you can elegantly turn over this issue by targeting newer APIs and including in the build path the support library. This is more elegant than the others because it is better to you focus in only one android version when building your application, and when it is done, you have an authentic version of your app that you can use as a mold to support other versions, either older or newers.
I'm moving from Eclipse to android studio and this is my set up in eclipse:
I have several Android app projects, depending on several library projects (some shared) all within one workspace. In Android studio I first started creating a project per app, but quickly realized that I would have to have the library projects as modules within each project that uses them. This would mean duplicating the library projects and including them in each app, which is highly redundant and would require maintaining multiple copies of the libraries.
So I switched to having all my apps and libraries as modules within the same project. This works for building but creates other problems such as version control issues since each module lives in a separate version control repository.
What is the cleanest way to have this setup? And the real question is, can I have separate projects in AS that share the same external library projects?
NOTE
With the release of Android Studio 0.5.0, this answer is obsolete, but I'll leave it below for reference. For more up-to-date instructions, see How to share a single library source across multiple projects
In Android Studio, it's difficult to have shared library projects, because currently it's a limitation that all modules in a project must live under the same root folder; it seems like you found this out when you tried to solve your problem by making one big project that includes everything. We're working on trying to lift this limitation.
The best answer right now is to make the library modules separate projects and have them publish to a local Maven repository, and have the dependent projects pull them in from that repo. This means that you can't work on your app + library module sources from the context of a single project, unfortunately. A bigger disadvantage is that source attachments for those library modules doesn't work yet, so if you're trying to debug your app, you'll have difficulty stepping into code in the libraries.
I know this isn't a very great answer, but at this stage of Android Studio's evolution, it's probably the best we can do. We know yours is a fairly common use case, and it's a priority for us to support it.
At the moment I have two versions of my App: normal and plus
When I puplish a new relese I export it and then change the packet name and export it a second time. The plus version has some additional features which get unlocked by the package name..
I just discovered Android Library Projects (http://bit.ly/voHVWe) and now I wonder if that could be solution for optimizing the workflow decribed above?
A further question is, are there any more (dis-)advantages of using library projects?
- or would you propose another workflow?
Library projects can help you do exactly what you're looking to do. They're essentially like having an external assembly. All shared code would be in the library project, and each application (in your case, normal and plus) could utilize or inherit from the shared library code.
One gotcha for the library projects is that you need to make sure the application projects are using the latest version of the library project if you make any changes to it. I've been bitten before when I made a change to a lib project, and built the application to find out that it was using the old code (in eclipse just select the greyed out project, right-click and refresh).
This is the preferred way of developing apps with common resources and source code. There are some considerations to be made that are covered in the Managing Projects Developer Guide article.
I am working with a complex library that, for historical reasons, is separated into two Android library projects that reference each other. Prior to r14 of the SDK, this worked fine. Each simply referred to the other's source code. We released a jar, and in Eclipse, applications could refer to the two library projects.
With r14, Eclipse tries to build a separate jar from each one. Since each references the other, they both fail. It may be necessary to construct a single new library project from the two. But that's development work and presents other problems. For now, I'd like to instruct Eclipse and ADT to handle them as before, i.e. not to build jars from them, just to reference the source. I've been digging, but I haven't yet found a way to do that.
Thanks in advance for any advice.
The answer is probably no. We worked around it using source links, which improves matters tremendously. This mechanism didn't work with previous ADT versions.
The other solution that would work is using apklib project that you create with the android maven plugin.