Develop Reference

GitHub Desktop won't detect changes when I make a build apk?

I'm building a voice recording app and right now I'm backing up all of my code to GitHub and a memory stick. Whenever I make it build it saves it into the file directory that GitHub desktop it's backing up, but it won't detect some of my files. Such as: app.iml and app-debug.apk.
Has anyone else had this problem and if you have fixed it could you tell me how?

Those files shouldn't be committed or relied on since you will need to rebuild the project anyway when you do a fresh checkout. Your code might be different than your compiled code depending of how you added them. Check out this thread that talks about javascript Should compiled JavaScript files be committed to Git repo?

Sounds like Git ignoring files and directories specified in the .gitignore file in the root of your repository directory.
See lines from one of my repositories:
*.iml
..
..
/build
Your apk file is just the latest build of your code, so the source code saved to GitHub is the backup.

Android Studio keeps adding additional files to GitHub

I'm using Android Studio 2.2.2, using the built in VCS tool. For some reason, Android Studio automatically adds a bunch of extra xml files and folders that I did not add nor edit.
More specifically, it's adding the following files when I don't want it to:
/_windows
IntelliLang.xml
debugger.xml
diff.xml
vcs.xml
web-browsers.xml
This makes making pull requests downright impossible as the master branch doesn't have these files, and none of my other group members seem to have this problem either.
Any help in removing / configuring Android Studio to stop this pesky bug?
--
edit: I am already using a gitignore file already. The weird thing is that my additional files are in the wrong folder too. Basically, my root folder, has a subfolder for my app. All the junk files are created in my root folder for some reason by Android Studio.
/root/
/_windows
IntelliLang.xml
debugger.xml
diff.xml
vcs.xml
web-browsers.xml
/my_android_app/
gitignore for my app
/files actually needed for my project

Turns out this feature is called "Settings Repository", and it's intended to save IDE settings automatically. I guess I might accidentally agree on some popup from IDEA which look like add files to the git repository, so this started working.
FIX: Open Preferences → Tools → Settings Repository → Delete. I also disabled Auto-Sync. Dunno where it's going to save if I delete everything, but I switch it off to be extra safe..

Use gitIgnore file.. i am currently using this .
*.iml
.gradle
/local.properties
/.idea/workspace.xml
/.idea/libraries
.DS_Store
/build
.externalNativeBuild
/captures
check if the same works for you or not ..
if you want to know the details please check here

If the IDE you are using is adding files that it requires, but which you don't want to be included in your repository, then this is a good candidate for additions to your .gitingore file.
Are you currently using a .gitignore file?
More information can be found here:
https://git-scm.com/docs/gitignore
You basically add an entry for each file or folder you want to ignore, and as a result, git will no longer try to include these files in commits going forward.
There is a good resource here:
https://github.com/github/gitignore
For creating a default .gitignore file. You would pick the .gitignore template that closely matches the type of development that you are doing, and customize from there. For example, I always start with the default Visual Studio template.
Probably the best suggestion would be to use the template .gitignore file for Android Development which is located here:
https://github.com/github/gitignore/blob/master/Android.gitignore
NOTE: I would copy the contents of this linked file into this answer, however, these template .gitignore files are always changing, as new recommendations are being added. It is best to keep referring to the source file for the most up to date version.
It doesn't explicitly ignore the files that you have mentioned, but it could be that those files are created within a folder that is being ignored.

Android studio - should the entire .idea directory be in git ignore?

I saw a lot of examples for .gitignore files for AndroidStudio, some have .idea in them, and some don't.
Is there a good reason not to add the entire .idea dir to .gitignore?
If it should not be completely ignored, are there specific files inside .idea (such as .iml) that should be in .gitignore?

You can take a look at this page :
IntelliJ doc about project configuration files
In the "Directory-based format", a particular line is interesting :
The .idea directory contains a set of configuration files (.xml). Each file contains only a portion of configuration data pertaining to a certain functional area which is reflected in the name of a file, for example, compiler.xml, encodings.xml, modules.xml.
Almost all of the files contain information core to the project itself, such as names and locations of its component modules, compiler settings, etc. Thus, these files may (and should) be kept under version control.
However, I properly HATE to make project IDE-dependent (I am currently working on a project made with NetBeans and it hurts to use it with Eclipse which becomes the standard of my company).
So, to answer your question :
If you do not use something like Maven or Gradle to manage dependencies and build : keep the directory under version control. This way, the correct configuration of the project and dependencies will be available for everyone. In the counterpart, all developers will have to set their environment exactly the same way that you define it in the config files.
If you do use something like Maven or Gradle : correctly configure these tools and do not keep the directory under version control. Actually, all the information contained inside config files should be stored in Maven/Gradle files. Then let your developers configure their IDE depending of their environment. This way, using Eclipse, IntelliJ, Linux, Windows ... will not be a problem anymore.

OK, so after some "Yes" and "No" answers, I am adding a "Yes and no" answer :)
The problem is that .idea is used for both project build configuration (dependencies declaration) and project settings (inspections, etc.).
You definitely don't want to use your IDE for your build configuration, but you might want to share the settings among the team. That's why you need to ignore only a part of the .idea content (like the libraries folder and the modules.xml file), but keep others in the version control (e.g. the copyright, dictionaries and inspectionProfiles folders and files under .idea like dynamic.xml, codeStyleSettings.xml, etc.).

The concept of keeping the project configuration in VC is valid. I did this with my team because all of our developers happened to use PHPStorm for our projects and so it made sense to keep a common configuration ... in concept. We wanted to use the same dictionary files, the same coding standard rules, and the same plugin configurations.
The reason why I qualify this with "in concept" is because there were issues with JetBrains' .idea folder that led to us not being able to use it. These were probably issues that could have been avoided or fixed, but it was unclear to us how to do it right, and we think that's a fault of JetBrains because as developers we do not have time nor desire to search for solutions on how to make our IDE work correctly.
That being said, the issues were had are the following:
Symlinking project folders doesn't work right.
When I set up my projects, I symlink them into my home directory. What we discovered was that the project was set-up to use the exact symlink rather than just treating it like a concrete directory. This means that if another developer keeps his project in a different place, or simply does not use symlinks, the entire directory will be missing from the project navigator because it is quite literally looking for the symlink. What's worse is that I could never find this path value in the configuration. We were unable to find the exact config in the files constituting our .idea folder.
Definition files are partitioned to users by default. This means if I want to add a word to my dictionary, it will be listed as a definition for me, jgreathouse, but other users will have their own definition section. The flagged words will still show up as a spelling mistake for other users. This is not desireable. The reason I add it to my definition file is because the IDE is wrong. I want these definitions to be intuitively shared with other users.
Colleagues kept overwriting the configurations because their IDE would overwrite the configurations with their config currently in Memory. What I mean is that, a developer would be working, and merge their repository from origin, which would contain a project configuration change, instead of their IDE changing configurations, or even giving them a choice, it would automatically overwrite the .idea configuration with the current in-memory configuration of their IDE. In my opinion this makes the .idea configuration unusable as a shared configuration. In order to work around this, the developer would literally have to shut down that instance of their IDE, pull the repo, and re-open their IDE. It makes no sense to keep a shared configuration if the IDE instantly overwrites it with the configuration currently in memory. It's like not having a shared configuration at all.
I've done these types of shared IDE configurations in VC before with Visual Studio and Netbeans and it was always fine; but with .idea it feels simply unusable which is disappointing. I wish JetBrains would get on top of it and make it a better user experience.

As a complement to the explanations in this question GitHub's .gitignore template for Android includes the following files:
# IntelliJ
*.iml
.idea/workspace.xml
.idea/tasks.xml
.idea/gradle.xml
.idea/assetWizardSettings.xml
.idea/dictionaries
.idea/libraries
# Android Studio 3 in .gitignore file.
.idea/caches
.idea/modules.xml
# Comment next line if keeping position of elements in Navigation Editor is relevant for you
.idea/navEditor.xml
Notice also this entry from JetBrains guidelines on How to manage projects under Version Control Systems about sharing IDE project files with other developers:
What needs to be shared:
All files under the .idea directory in the project root except the
items that store user-specific settings: workspace.xml
usage.statistics.xml shelf directory

Eclipse overrides existing project files when importing existing project

I'm working on an existing project from my wd of git.
.classpath and default.properties files are on the repository.
When I import the project to Eclipse, my default.properties is replaced by a project.properties (the files' contents are the same) and my .classpath is modified.
As I said, these files are on the repository, so my git status is never clean.
Do you know how to force Eclipse using the files provided on the repository without modifying them ?
Thanks

default.properties (or project.properties)
Check out the changelog of SDK r14 release:
default.properties which is the main project’s properties file containing information such as the build platform target and the library dependencies has been renamed project.properties
If someone from your development team still use a version older than r14, better to ask them upgrade to latest Android SDK version on their workstation, as the Android SDK has been changed rapidly since r14 regarding to project property file, library project, external jar dependency structure and etc. It will make development very hard to maintain if developers use different Android SDK version in a team.
If this is not an option in a short term, you should temporarily create and check-in both default.properties and project.properties (with the same contents) for a short period of time, to support old Android version in a short term and give other people time to upgrade their workstation.
.classpath
It is a very bad practice to commit IDE generated files (.classpath, .project and etc.) into source control. Do you expect .classpath generated from a Windows box has exact the same contents as the one generated from a Mac box? You should add .classpath to your source control ignore list so that it is ignored automatically whenever you commit your project to source control.
When use a source control system, Don't consider too much for every single commit, as long as you provide fully detailed comments. as every single action (add, modified, deleted and etc.) you did on every single file (java source, properties and resources file and etc.) in your project are logged and tracked in source control, in case if something goes wrong, it is quite easy for a sophisticated developer to track the change and revert the project into a normal state. Hope this helps.

What goes into Source Control?

Given: http://developer.android.com/resources/faq/commontasks.html#filelist
What are the best practices for getting your projects into source control? I ask because if you simply right click on your project, choose team, etc. you end up with the /bin & /gen folders, .classpath as well as all the Eclipse related items.
If I'm inheriting a project with .../workspace/projectName et al. included how can I clean that up to include only the items relevant to the aforementioned URL?

I summarized all my findings in a blog post that can be found here: http://www.aydabtudev.com/2011/05/what-goes-into-source-control-android.html
I executed the following commands from within my project folder to get them out of source control:
svn rm --keep-local .classpath
svn rm --keep-local .project
svn rm --keep-local default.properties
svn rm --keep-local proguard.cfg
svn rm --keep-local bin/
svn rm --keep-local gen/
Then I executed the following command to add them to an ignore list:
svn pe svn:ignore .
Add each item above without the associated command like so:
.classpath
.project
bin/
...
I followed that up with a commit and an update to solidify my changes.
svn commit -q -m "Removing files" .
svn update
It would seem the smarter way to do this would be to configure the Ignored Resources under the Eclipse Team preferences.

If you're using SVN, you should selectively add files/directories to your repository.
For example with the following directory structure (quick example from my disk):
res/
src/
build/
.idea/
You do not want the build directory, nor the personal preferences for your IDE (.idea folder) adding, so you would only issue the command: svn add res src
To (I think) answer your second point, I'd manage everything to do with version control from command line initially, and then let your IDE do it.
My apologies if I'm missing the point of the question.

Here are some basic points:
Don't store stuff in version control that your source code produces. For example, if you build a jarfile, don't store that jarfile under source control.
Source control is for source. If you have releases, use a release repository like Artifactory. Don't let the Maven stuff scare you away. Maybe you don't use Maven (now), but a Maven repository tool is in standard format, and makes it easy to find your releases. Artifactory can work with Ant/Ivy, and with a little elbow grease, you can get it to work with C and C++ projects too.
Which brings me to the next statement: Don't store your jarfiles (if you're a Java project) in your source repository. It's convenient, but you'll end up hating yourself for it in the long run. Binary files take a long time to process in many source control systems and they can take up lots of room. What's even worse is that you lose information about them. For example what version of common-utils.jar is checked into Subversion that my project now depends upon. Again, use Artifactory and Ant/Ivy or Maven. If you're non-Java, you can use wget or curl to fetch your dependent libraries out of Artifactory. Again, don't let the whole Maven thing scare you.
If you have a Java project, and you don't use Maven, insist that code is stored in the repository using Maven's standard layout. That is, Java code is stored under src/main/java and non Java files are under src/main/resources. The advantage is that it makes it easy to move from project to project, and new developers can quickly find where things are. Plus, it makes your build.xml files much cleaner. You can use any standard repository layout you want, but by insisting on Maven's standard, you can squelch all complaints. "Hey, I agree with you, but Maven says you put your code under this directory. Sorry, I wish I could help, but my hands are tied"
If you're using Subversion, stick with the standard, trunk, branches, tags style and don't be too fancy. I'm not 100% crazy about the layout myself. (I'd rather have a main under the branches directory and no trunk), but you'll simply confuse developers and make support more difficult, and all for very little gain.
Make sure all projects (if you're using Ant) have standard target names. Again, I borrow Maven's naming convention. Make sure all build.xml use the description parameter in target names, and that internal only targets don't use description. That way, ant -p works. Also make sure that all built artifacts are under the target directory (again, Maven's way). It makes it easy to do a clean if you only have to delete the target directory. The idea of clean is to restore your layout to pristine checkout condition. Makes it much easier to use a tool like Jenkins. Which reminds me...
Use a continuous build tool like Jenkins. It helps you enforce your policy and standards. Unlike many tools, developers actually like Jenkins. And, you can add stuff like automatic testing, checkstyle, etc.

1.
It depends on your workflow. If you expect everybody who will ever work on your project to use eclipse having the .classpath folder in there is good because it keeps all your settings(library paths, external dependencies..)
To the best of my knowledge subclipse doesn't put the /bin folder under version control(it probably happened because of the weird way the repository shaped as you describe in 2.) because eclipse can generate that one on the fly as soon as it has the /src folder.
usually moving everything under /workspace/projectName to / and deleting /workspace is sufficient.