When you are working with AOSP repo you can create a local manifest folder and store your own manifest files for your own projects. As our project grows though we continue to add more projects to our manifest. We track this manifest file on git so we can all stay current.
The problem is that when you call repo sync you have to pull all the changes to your local manifest file first. If you don't you may miss out on required projects someone else has added. Well, repo is capable of syncing it's own manifest file and does so automatically when you call repo sync. Is there a way to have our own manifest file also get updated automatically at the same time before the actual sync occurs? I'd rather not use some extra script to do it, it would be really awesome if repo could handle this on it's own and I feel like it should be able to.
This sounds like a reasonable request. You might want to post it to the repo-discuss mailing list to get some traction (or get an explanation why it's a bad idea).
From my point of view, the point of local manifests is that they're... local. If you want to persist changes and share between different users via Git, why not modify the original manifest file (typically default.xml)? You've branched the manifest git anyway, and adding a separate section with your gits shouldn't cause much grief when merging.
Related
For a mistake i've overwritten my two project that has same names from android studio and i've dismissed that action today i've tryed to open the main project and i've found no Java classes in it and just the layout's files.
While in the second project to which i was overwritting there is a huge confusion of files and trying to recover the project version by using history of Android Studio even those files has disappeared.
Is it possible in anyway to recover the whole project?
Ps: all that remain from that project is a generated apk.
I have some solutions that may work.
Candidates are:
Search for $AppData$ folders
Search for registries
(Hardest) you may have to preserve the disk state and carve the files yourself..
Cheers, and hope it helped..!
To use the third method(file carving), you may not cause many file operations occur!!(The system may overwrite the previous data)
Hopefully you used source control such as git or svn and it is a simple matter of reverting to the last commit you made, however that is done in your chosen source control. If you don't use source control, perhaps this will serve as a lesson to do so in the future.
I've not used Android Studio, but as a JetBrains product like IntelliJ, it will have a local history record of changes. But that would only record very recent changes.
If that doesn't work, you may have to find out if your chosen operating system backed up the files in a restore point etc.
If you have turned on the file history, you can use that to go to a previous version of the folder. Can also use system restore to go back to a previous date. Can also use third party softwares such as Recuva to get deleted files back.
Make sure to keep a copy of current state somewhere before trying these out.
I've been using repo for quiet a long time now but never bothered to know what <remove-project> in manifest.xml does.
What does <remove-project> do — it doesn't download the project at all or it downloads it but removes it from codebase later?
It's here somewhere but I'm pretty bad at reading python.
https://gerrit.googlesource.com/git-repo/+/master/docs/manifest-format.md#Element-remove_project
Element remove-project
Deletes the named project from the internal manifest table, possibly allowing a subsequent project element in the same manifest file to replace the project with a different source.
This element is mostly useful in a local manifest file, where the user can remove a project, and possibly replace it with their own definition.
I have an android project, and mistakenly added bin folder to stage and committed it. Now how can I ignore this bin folder and ignore it for ever?
I added bin/ to the .gitignore file, but nothing changes and I see all files in this folder in working copy in SourceTree.
I am using SourceTree as the git client.
Along with ignoring the folder, you need to git rm it. Git only ignores files that aren't already under its control.
Be aware, though: doing so will cause git to remove that folder for anyone else who pulls those changes. You'd better be sure that folder is just the output from building, or can otherwise be easily reconstructed.
If you haven't published the changes yet (that is, if you've never pushed them to anywhere and no one's pulled them from you), then you have the option of rewriting the history. You can simply say git reset --soft the_commit_before_you_added_bin (of course, you'll need the actual commit ID, or another name for it, like HEAD~3 etc) to basically "uncommit" to right before you added it. Your working copy will still have the latest versions of the files, but Git will all but forget you committed them. (This also means you lose intermediate changes.) You can then redo your commit(s), being careful to avoid bin this time.
Git has a filter-branch command that can allegedly help with automating all that, and can even preserve intermediate changes. I've never used it, though, and couldn't tell you how to use it.
Obligatory Big Bold Warning:
Don't rewrite history that has already been published.
Only undo/rewrite commits that have never been pushed or pulled. Otherwise, wackiness ensues.
So I'm not sure if this is possible but I'm hoping it is. Basically, we just moved to SVN from Sourcesafe (I know a lot of you almost threw up in your mouth just now ;)) and I'm setting up eclipse to work with it. I installed Subversive and have a repo set up with my project. Just FYI, I'm working on an Android project written in Java. Here's what I want:
As I'm working on each Java file making changes, I want to write the SVN Commit Messages right their in code just as I add javadoc comments. This is because I have to change a ton of files before I commit and I want to remember each thing I changed (client requirement). But I don't want to have to remember all of that (especially as I'm deleting a lot of code) and them add the comments when I commit all my changes from all my files. Ideally, I simply add some tag and then the commit message that SVN understands and as I commit the file, I don't have to manually add the comments but it gets done automatically based on the commit messages tagged in my source file?
As an example, say I deleted a function foo in footest.java, I would simply type in the following in footest.java:
// __ (hopefully some tag here) deleted foo
Now when footest.java is commmitted, I don't have to type anything, the commit message 'deleted foo' gets added to it.
Finally, ideally, this is done automatically per revision. That is, once I make another change in footest.java, say, added function newfoo(), I could tag it like before with comment "added newfoo()" and when I commit only "added newfoo" comment gets put on the revision and not the one for the previous version "deleted foo".
Is this possible? Any issue anyone sees here?
Thanks,
-Vivek
Generally speaking, mixing your commit messages & your code is discouraged.
Subversion (or any client I'm aware of) has nothing of the kind built in, because it would require knowledge of the code itself and your custom markup.
You would need to write a wrapper around svn commit (or your client's equivalent) to process your files.
But have you considered that to do this right, you'd also have to remove those comments from your code once you've committed the changes? Now you're into your wrapper script messing with your code - and a bug there could break your code, either introducing subtle, hard-to-find bugs or rendering it impossible to compile.
Why not just keep a text file on your desktop with your notes? Or make smaller self-contained commits instead of delaying until the point where you've forgotten why you made some of the changes?
I have a small Android application that uses different sets of files (a couple of images, a small SQLite DB and a couple of XML files) depending on the specific task at hand.
I know I can include my files into the main application APK using resources or assets but I would be happy to distribute them in a separated APK.
How can I create a data-only APK file?
How can I distribute it? In particular, do I have to do anything special for a data-only package (for example for associating it to the main application package in some way)?
(I'm intentioned to give the user a link to the data package and ask him to install it. No automatic installation required.)
How can I install my files into the internal or into the external storage area of my application? Is it possible at all to install files into the internal storage area created by the main application installer? Do I have to set any particular permission for this?
My approach to this would be to create a wrapper app that's nothing but a content-provider and serves up the files per request by your main app. This would allow you to supply different data packages for the user -- you could even have your main app select between those relatively easily.
It looks like that the commonly accepted way to have the same application with different contents (or styles, or configurations) is to use an Android Library Project for the common code (that is: the whole application, the "engine", the "app framework") and a standard Android Application Project for the contents (that is: an application that actually contains just data). A little bit confusing, just because the "library" here is actually the whole "app", but this seems to be the way to go.
More in detail:
Create an Android Library Application and put into it as much code as you can (all of the non-changing stuff). Please note that this library cannot be launched and cannot be distributed alone. It must be included in a hosting application.
Create a standard Android Application. Include your library into this project. Put in /res and in /asset all of your data (files, XML, etc.).
Compile everything and distribute.
Repeat this cycle every time you need a different version. Different because of data, style, configuration or anything else. Publish the resulting app with a new name.
For what regards me, I'm not completely satisfied by this approach.
A possible alternative is preprocessing the source code with Ruby, Python, Perl, GIT, bash, Ant, Maven, Rake or any other tool that is able to read a file from here, make some change here and there, and write the file there.
The general outline is something like this:
Make a "template" application. Leave your /res and /assset empty.
Run a custom-made script. The script reads a configuration file, copy the /res and /asset files from your repository into the project /res and /asset directories, changes some Java source file and creates/changes some XML file.
Compile and distribute (with a new name, of course).
Using GIT or other SCMs, you just make a new branch for every new version and compile it. Not very elegant (because it can strongly interfere with the normal use of the SCM) but...
There are a few example of these approaches on the web. I'm not completely satisfied by them, either.
Frankly, what the Android ecosystem should offer to solve this problem is some kind of "in-app package manager". Something like the Eclipse Update Manager. This would allow us to use the same application framework to handle different scenarios.
As an alternative, a solid, officially-supported, template-based code-generation mechanism would be nice. Something in the spirit of "Software Production Line": https://en.wikipedia.org/wiki/Software_production_line . Have a look at fw4spl, for example: http://code.google.com/p/fw4spl/ .