I want to fork an Android project (a normal application) from the official repository. After I clone the project and import it into Eclipse, I still have loads of different missing references to some other projects that prevent me from even looking at the layout ressources (as it tells me to fix the Java errors first).
Is there a way to fix those references, without using repo or cloning the whole repository (with all its projects)? After all I’m only interested in a single standard application there.
If it is using anything that is not the official SDK, you'll have to fetch it to get it compile. You can import in Eclipse if you have the whole thing.
BTW, cloning the whole repository is worthed, because you can grep to search for things, even if you don't intend to compile it.
For changing an App that is based on the whole Android repo, you really have to have the whole repo with you. Then you can just change that App and make that App, for example using "make Email". That will only build the Email.apk and not the whole ROM.
Related
I have a single Github repo that contains 5 Android projects. Say one of the projects is named ToysGift and I want to change that project name to ToyDrive. How do I do that?
I am using Android Studio. Can I just change the name of the project in Android Studio and then push to Github? Git always proves challenging for me that's why I am asking first before trying different things because once I break what I have, I won't know how to get back to a good git state.
Did a quick test, Just changing the project name in android studio and then pushing should work, just make sure you have everything pulled so there aren't any conflicts.
I am trying to transition all our projects from Eclipse to Android Studio (Finally decided i had to do it..!) but i am fighting seriously with the way how Android Studio / gradle works - in regard to using external library projects.
Until now in Eclipse - we used to have all the dependent projects in the same workspace and they where 'shared' amongst all projects which were under development.
That made it extremely nice to do changes on the external changes and commit them separately to their own SVN repos - while the projects using them - to take advantage of the changes without thinking.
That goes specifically to one library - our own framework which we use for all android projects and it is constantly being developed, altered, partially reworked and used by several people.
But then came Android Studio... the problem is that say if i have an example project with 10 sublibrary dependencies, including our framework - Android Studio with physically COPY all files into a subfolder of the main root project - loosing all the capabilities to 'commit' changes later being done to the sub libraries - to their own SVN repos.
I've tried pretty much everything, i think i've read everything :) but crap - nothing seems to 'fix' my work case..
I tried to checkout one sublibrary in the already checked out root folder of the root project and tried to import it into it - but ofcourse Android Studio says 'library already exists' - so that doesn't work. Even if it did... the library itself has its own deps and what i saw is that Android Studio will decouple them upon import and put them at the same level in the root project.. which completely messes everything up.
So my question is - even if i understand this is no longer possible - is there any EASY way i can at least COMMIT BACK to the SVN repo of the sublibrary from within the root owning project - using Android Studio (by easy i mean from the UI directly without needing to mess with manual console merge hazzle...)
I can't understand how anyone has not solved this yet - i am sure everyone is doing this one way or another?
Could someone share a good practice way of 'doing' it? :)
THANK YOU!
What i did:
Switched to: git
Converted our subprojects to git from svn
Made all subprojects externals of the primary project
Included the subprojects in gradle with the help of this post: Android Studio 0.8.1 Creating Modules without copying files?
Cons:
Not fully manageable from Android Studio - have to do half commits in Studio, the other half + pushes in console - so i ditched Studio completely and moved all to console once again. May be this ain't so bad after all :)
What i did was use Blundell's advice - although i really... really ... REALLY didn't want to go switching completely to git...
We have over 300 repos here in SVN and it's really not the time to start the git hazzle...
But this was the only workable solution so far as git externals make it really really easy to work in such way.
The f**** up thing about this is that half work has to go to console again... Externals and adding git remotes can't be managed from Android Studio... Life, i guess :)
I am working on an android project that have later to be translated to many other languages and some changes have to do in design.
Now I want to know is there any way to make one project and keep it on git and later having changes should change the git project accordingly. So is it possible to create multiple apps for Android project. If yes, is it possible with Eclipse and git or someone has any other idea?
For the time being I am saving project in local directory and copy that project to make changes for next app.
This sounds that you should give git-subtrees a try. There, you create one repo with your base project and then import this repo into your specific app project. If you want to propagate your changes to the API, you push the changes to the base repo. We use this for component development.
But from my experience: do not use eclipse for working with git. It has some major drawbacks and might corrupt the repos. Use the CLI or another tool.
So, this is not like other problems. I have basically one question
Android project build system uses the Android.mk files.
Is there any eclipse plugin out there that parses through the mk files and allows me to load those projects into eclipse ? essentially import Android.mk file project...
You can import the whole Android sources into eclipse. The instructions are here. Then you should make some modifications (for instance, include android-common_intermediates/javalib.jar instead of google-common_intermediates/javalib.jar) and you will have possibility to develop in eclipse.
Eclipse separates Android sources to several projects by itself(I think according to classpath entries). If you want to change this behavior you should look in this direction.
If you have tried eclipse instructions at Android source site, you probably would know by now that it leaves lot of details to imagination.
One thing you need to keep in mind is that AOSP build doesn't work with eclipse. As long as you build your code from terminal and use eclipse to edit/browse/debug purposes, you will have more productive sessions.
The article at Using Eclipse to browse/edit Android platform code explains this in step by step.
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.