When I start my (soon-to-be) android game (from eclipse) it opens, but immediately force-closes.
Logcat says:
07-09 17:12:35.709: ERROR/AndroidRuntim
I use Perforce with Eclipse and have discovered that Perforce's default behavior of making all files under source control read-only causes build problems that aren't clearly specified in Eclipse's build window. Also, there seems to be a quirk for me when adding a library project where even if the .classpath and .project file are writable the library may not properly associate itself with the project. I generally follow these steps for resolving errors of this nature (this assumes that the project's manifest is correct):
1) Close Eclipse. Eclipse may cache some info about a file's R/W status.
2) (Broad stroke) Make all of the files in the project writable either by checking them out from source control, or through the OS. .classpath and .project at the bare minimum should be writable.
2.5) If you placed files under source control that are generated during the build process and are a normal part of the Android build process then they should be removed from source control and made writable. Including but not limited to .class and files in the bin and gen directories.
3) Open the project in Eclipse. If there are no errors the problem may be fixed.
4) Examine the project explorer and look specifically for library project dependencies that may be missing. In my experience it's important to see all lib projects' directories and their library status icon in your project's explorer hierarchy. If a lib project folder and icon is missing, go to Properties->Android and select and add the missing lib(s). After adding a lib select "Apply" an watch the project explorer to make sure that the lib icon appears in the project directory. This step explanation may seem overly detailed, but I've been bitten several times before forcing myself to be extra observant here. If a lib won't add, try adding other dummy lib project and removing them in combination with the lib you want. No joke - this is sometimes necessary for me.
5) Clean all of the projects.
6) Read the error list and resolve any other errors.
7) Fix all of the warnings you've been putting off fixing.
8) (Not essential but important) Revert all unchanged files and observe what's left in you changelist - these are the files that will need your attention in the future to prevent build problems.
I had this problem once when my working application suddenly started throwing ClassNotFoundException. The problem was that the classes were not being compiled and translated to the "dex" file, this is obvious to find because the APK just shrinks.
So, in eclipse, in order to fix it just add the javabuilder to your .project file.
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
Hope it helps.
Perhaps your run configuration refers to the old name. Click on the little triangle next to the green run button, and select Run Configurations. Make sure the one for this project refers to the right activity name. Or just delete it and Eclipse will automatically make you a new one.
I got this error in a FragmentActivity after updating the SDK to Android 4. The reason was, that you no longer need to include the android-support-v4.jar. Just add the support tools by clicking right mouse button on your Project, than Android Tools -> Add support library.
Just had the same problem. After updating ADT to the newest version, my
libfolder was no longer recognized. Had to rename it to
libsNow: do they really have to release new SDK every 5 minutes? Can't they create ONE stable environment for some longer time?
Try to fix .classpath.
Had the same problem caused by corrupt .classpath file. After fixing it the ClassNotFoundException was gone.
The background is that we are using SVN, an update caused a conflict in .classpath. Eclipse, however, did not show any error message or hint about that. I only found out when I tried to submit the current changes.
The solution here was to do a fresh SVN check out of the project, so a working version of .classpath was restored.