I have recently started to look into android development (aosp) and read about "repo" tool/wrapper that takes care of all the android's sub projects .
While I think repo does a fairly good job at what it does, I wanted to know if there are any alternatives to it.
I thought git submodules are sufficient for this but many posts on internet discourage use of submodules ( due to some "drawbacks" which I feel are not drawbacks at all ).
Keeping in mind that the source code for different sub projects should have their own releases or indipendednt code bases I am not sure if git subtree is a good solution for this.
It would be great if someone can point out some alternatives to repo or any other information about this.
The repo tool is the standard way to work with AOSP code base. Sure you can manually manage the repos yourself but that is going to be rather tiresome and error prone.
Otherwise using submodules or subtrees won't let you inter-operate with Google and everyone else working on the AOSP codebase, so unless you are planning to do a one-way fork of AOSP there are no alternatives to the repo tool for working on AOSP.
repo has one huge disadvantage: it detaches HEADs. You can't switch to specific branch under specific subrepo. Unless you do repo start
tsrc, as far as I know, has less functionality but doesn't have this specific problem.
Also, you can use embedded mechanisms of build systems like Bazel (git_repository/new_git_repository).
Related
Fetching the AOSP source, is 134GB.
A checkout of a particular version of Android is likely to be many GBs.
How do developers who customise AOSP keep their changes under (their own) version control? (Given that checking-in a snapshot of an Android version's source will be many GBs.)
This is my flow, maybe not the best....
I don't like dealing with repo tool and multiple remotes, so I get rid of all the .git subfolders and create just one tremendously huge repository. This has the bad effect of essentially removing all the "history". So we have a server with the original sync for git blame if we need to.
First check-out for a developer will be time-consuming either way. To make it faster, we have a local bare git repo cloned. So people run git clone on the local server, and the switch the origin to the actual remote.
After all is set-up, the day-to-day dealings are not time consuming. Commits and pushes are quite fast ( maybe 5-10s ) even for a large repo like this. Thanks GIT!
Sorry for necro-posting, but maybe somebody find it useful.
I just use repo utility from Google, e.g. repo start.
Only first repo sync procedure take a long time,
even subsequent checkouts do not like so time-consuming.
If you check some popular ROM, e.g. GrapheneOS, you find they repo too.
I have multiple Android applications, and I've created a common Android library project, and a common Java library project (The Android library project compiles the java one). These libraries are filled with common components that I use for all my Android apps.
I'm using gradle as my build system.
I'm using git for versioning.
What would be the best way to link everything together? Keep in mind things are still being added / changed in the library, and I need a way to propagate changes to all the Android apps. Copy / Paste wouldn't be a great option. I've tried a few things, and they aren't working out very well, so I'd love some input.
EDIT: It's probably also worth mentioning that multiple people are working on these projects. It's not just me.
The current version of Android Studio has a limitation that all of its modules must be under the project's root directory in the filesystem, and this limitation hampers a lot of people in your situation, because frequently they want those common libraries to live someplace else. It seems like this is the case for you as well.
We're in the process of lifting this limitation in Android Studio, and soon you'll be able to have modules outside the project root. I think this might be the best solution for you -- you can pull your common libraries from wherever makes sense in source control, put them wherever makes sense in your filesystem, and link them up into whatever projects need them. However, this isn't available yet, but will show up in v0.5.0, which will hopefully go out this week. I haven't personally tested it in our dev builds and can't vouch for how well it works, but at any rate it should be coming along soon.
Some developers have worked around the limitations by adding script to their settings.gradle files to set different module root directories. They say it works, but I find it a little scary because the IDE just isn't expecting things to work that way, and I don't know for sure if there are problems with it.
If you read other answers to this question on Stack Overflow, they're written before this feature was implemented and will have different advice. If you don't want to wait for 0.5.0 or there are problems in it that prevent you from using it, you can follow that general advice, which is to have your common code compile to libraries that you publish to a Maven repository (which can be local to your machine or common to the developers in your group), and pick up those libraries with Maven-style dependency statements in the projects that need them. This has the disadvantage that you'll need to open up separate projects to edit the code in those libraries, along with a more complex build process, but it will work.
Imagine mobile application that is planned to be implemented for both iOS and Android.
Development was started from the iOS version only and now the time has come to start with Android one.
iOS application's code is stored at its' own Git repository that named after the apps name, e.g. "MYApp".
Now I would like to create one common repository for both iOS and Android applications and name it again after application's name: "MYApp".
It is not a problem at first glance.
Just create repository, create 2 subfolders there and start working.
But.
I would like that Android developer could work only with his folder and iOS developer only with his one too and both of them could see only their own folders related history (log).
I worked with SVN previously.
Usually I created subfolders and you could checkout any of them to work only with this subfolder.
History was also filtered to your scope.
I'm stuck with implementing the same under Git.
Please, help me to find right direction.
I will sum up solutions suggested.
Use branching for different platforms. I don't think that it is good idea, because branches used for another purpose. It seems to me very "jacky".
Use submodules. Just create as many repos as platforms you are targeting to, name them "MYApp-iOS", "MyApp-Android", etc. and finally end up with "master" repo, that could be names as "MYApp" (without any suffixes). Then add all related repos to "master" one with git submodules feature.
Use git slave. Investigating...
Please, feel free to edit this list to brainstorm the problem.
There is a way to keep to kind-of-related separate projects in a same git repository utilising git branching.
But keep in mind that that is not why branching was implemented into git. One of its uses would be development of a radical new functionality to your app that might not see the release any time soon for example.
On the end: it is a matter of opinion. If you are prepared to administrate a more complex repository just to keep both codes on the same place - you can.
I would definetly make two separate repositories though. Couple of opinions on this topic can also be found here on SO: Git branches with completely different content
EDIT:
gitslave seems to tackle your problem. You might want to give it a try.
I am taking care of an open source project: mixare. It's an augmented reality browser released under the GPLv3.
The source code of the project is on github and I would like to hook the localization part to some web-service a-la pootle. If necessary I can install my own instance of a translation service on our server, but also an hosted solution would be fine. So I would like to know:
Is there a preferred translation web service that syncs using github's service hooks? Any best practice to share?
Thanks a lot!
Git integration is one of major reasons why I started to write Weblate. It also supports remote trigger for git pull using URL, so it nicely integrates with Github (you just need to put the URL there).
PS: I've just noticed that Android string resources are not supported by backend I use for loading translations (translate toolkit), so it probably won't work for you...
While I appreciate your wish for git support, shouldn't you primarily be looking for a solution that will give you many and good translations?
To get many translations I'd recommend Translatewiki, unfortunately their manual setup takes some time though.
Apart from Translatewiki, transifex seems to be one of the better and not least bigger (counting translators) services. They've made their own client that take care of importing and merging translations. For gettext translations it can also pull in updated template (pot) files automatically from github, I don't know if that's also possible with Android style translations.
Both Translatewiki and Transifex are 100% free and open source software.
I've been through the same "nothing good out there" phase, so I've started writing my own, as a symfony2 bundle. Maybe it's of use to you: https://github.com/tvogt/translator-bundle
Why? Because I couldn't get weblate or pootle to work, you probably have to be familiar with all the pip and python and ve and whatever stuff. Translatewiki is only for free software. Transifix is commercial.
In 2020, with GitHub Actions (hooks executed on GitHub side), you now have GitLocalize
GitLocalize is a continuous localization tool built for communities and teams that want to simplify their workflow when translating their content.
GitLocalize automatically keeps translations up to date by syncing with your repository.
That won't apply to the OP's project github.com/mixare/mixare, which was moved to GitLab in 2018.
But it can help other projects with a similar need.
You can have a look at Amanuens - it's able to sync with any Git repository, including Github. It's totally free for open-source projects (contact support for details). Disclaimer: it is my company's service.
Just curious whether folks still use CVS or if there are other versioning programs out there these days. Been out of software development for a few years and just kind of have the itch to play around a bit with some mobile development. I'd like something that I can share with at least one other remotely-located developer. Is there an industry standard or a particular program that most folks doing android development use?
Thanks!
Steve
CVS? Ancient history. It's either Subversion or Git these days. The type of development seems immaterial to where you archive it.
I use Mercurial (hg) DVCS to manage my projects (not just for Java, but also C and Python).
IMHO Mercurial is quite a modern VCS with very good support for merging (it has to since it is a DVCS).
If you are going to be working in parallel and doing lots of merges I'd recommend Mercurial.
If you are going to contribute to Android, you want to use git. Google has a layer on top of it called repo, which does a good job of dealing with the problem space they are dealing with.
If your last exposure was CVS, however, you may find that git is so much more powerful that it becomes confusing. hg is very good alternative. If you have a project which you are sure will never branch, and you need it to be PHB friendly, I recommend SVN.