We Keep Coding

PhoneGap Android "Could not find *.apk" [duplicate]

I know this question has been asked before and I have seen a plethora of solutions out there, yet none seem to work for me. I was able to build my apk without issues until this error started cropping up. I have tried cleaning my project, removing it from the workspace and reimporting it, removing "Java Builder" from my Builders for the project, building the project manually, reordering my java build path. I have no visible compiler issues and no problems exist in my workspace.
I did experience this issue before and solved it once by removing the project form my workspace and re-importing it and another time I solved it by removing "Java Builder" from my java build path. None seem to work this time. I currently have most of the settings set back to default (i.e. java build is checked again).
I am running windows 7 (64 bit) and using jdk1.6.0_21 via Eclipse 3.6.
Any suggestions would be greatly appreciated as I have lost loads of development time troubleshooting this already.
[Update] My locale is English & I have tried removing the debug.keystore, United States as related to issue 834

Please follow these steps; this might help you out:
Right-click your app project and go to Properties
Select Android from left-hand side list
Uncheck the "Is Library" checkbox
If your app project relies on library projects which are in your workspace, those of course need to have the "Is Library" box checked.

deleting the R.Java file in /Gen folder did the trick for me

I tried all the above solutions. but it didn't work.
The solution was to restart eclipse !!!!!!!
hope this will help someone :)

In my case this problem started after eclipse updated the plugin with the v4.0 API release. I fixed it by going to the main preferences for Eclipse and under Android->Build uncheck 'Skip packaging and dexing until export or launch'
Note: if you eclipse gives you the Unknown Command 'crunch' error then follow this post

I've tried to gather the best of other peoples answers into a step by step list of things to try in order:
Check the project is not set as a library:
Go to Project->Properties
Select Android from left-hand side list
Uncheck the "Is Library" checkbox
Clean and rebuild the project - this should delete and recreate the entire gen folder, including the R.java file mentioned in some peoples answers
Check eclipse and all the Android plugins are up to date
Close the project, exit Eclipse, reopen eclipse, reopen the project.
Go to Java Build Path > Projects and check for any incorrect project dependencies
Go to the main preferences for Eclipse and under Android->Build uncheck 'Skip packaging and dexing until export or launch'
Check JAVA_HOME is set correctly. Follow the steps in this article
If you complete the above list, and still haven't solved the issue, please leave a comment, or if you find something else that works, feel free to edit the answer and add your thing in.

Delete the project from your workspace & import again.
This worked for me.
Can't believe similar issue has been there since 2008.
http://code.google.com/p/android/issues/detail?id=834.

i'm no expert, but eclipse on Windows, doing android apps, refuses to create the default.properties file (in the app root directory). I've just copied one from another app and it works fine. Simple contents, for Android 2.2 project it just says (ignoring comments):
target=android-8
fwiw

I was having the same issue as the OP except that all these suggestions did not work. I found a solution for me.
Make sure that "Skip packaging and dexing until export or launch." is selected.
Go to Window -> Preferences -> Android -> Build. Just make sure that option is selected and apply.
I know this does not make a lot of sense, but having it unselected was giving me this error and with it selected it goes away and the apk is installed.
I am using the auto generated ant build script from android and ONLY using it as my build process in eclipse. I am not using any other build methods.

I figured it out. I was referencing JavaSE-1.5 and using JDK 1.6. I changed it to use 1.6 and that appears to fix it.
Seems like through my research that is an overloaded error message that covers a lot of error cases.

I just fixed this by reselecting a default JRE for the execution environment (JRE6 for JavaSE-1.6 in my case). It got unchecked for some reason.

This fixed my problem. I kept getting the console error in eclipse "Could not find com_android_vending_licensing.apk" and even though it didnt seem to effect the way my app ran, it was annoying. So going into the com_android_vending_licensing project properties and unchecking the "is library" option, building the project to produce the needed apk and then going back into the com_android_vending_licensing project properties and re checking the "is library" check box fixed the problem.

Run Eclipse as "Administrator" and then import the project.

None of these things worked for me. I'm trying to access native code through the jni, first with NDK samples. What I found was the build won't run if jarlist.cache is not present in the project bin directory. If I copy one from another project to that location (may need to refresh to see the folder in Eclipse), build works every time.

Clean the project and it will do. Sometimes it happens unknowingly but keep trying to solve using diff methods.

I had somehow done a Run configuration as a Java application instead of a Android.

the problem for me was I was trying to use IBM RAD which appears to not work properly for this, I installed Eclipse and now have a different error but I should be able to get past it

On my machine (Windows7, 64bit) I could fix this by setting my execution environment to a 32bit variant of the jdk (I used 1.6.0_23). And I tried a lot of things before...

SHA1's answer did it for me: after updating to the latest sdk/adt, my project refused to build an apk; unchecking the option resolved the issue.
I don't know if the update checked this, or if it was checked before but the new adt screwed things up, but things work again now :)

In my case this worked :
Delete R.Java file in /Gen folder
+
Delete all "R.Android" imports that Eclipse added to some of my java classes !!!
and rebuild the project.

remove -- R.java -- Clean the project and run again.. this worked for me ..

Find the project's folder in your system, enter it's Properties via context menu and deselect "Read only" option. Worked in my case.
This seems to be the source of the problem in many cases, moreover some solutions up there base on copying/rewriting the files in the project what makes them non-read-only.

This is caused by JAVA_HOME not being set correctly. It can be easily resolved by following the steps in this article.

Mine was caused by this problem (incompatibility between ADT and SDK), and was fixed thus:
Eclipse > Help
Install New Software
Add 'https://dl-ssl.google.com/android/eclipse/' to 'Work With'
section and press enter
After developer tools appears on the list, check it and click Next
Restart eclipse once download is finished

I my case, I had to switch from API 21 to API 19, clean and build and everything was fine again. I am using a Mac and apparently API 21 is not fully supported on Yosemite.

Why is Eclipse hanging at 57% with the status "Verifying launch attributes..." when launching a run configuration?

After recently converting to Maven from Ant, run configurations that launched immediately pre-Maven take an excessive amount of time and consume an abnormal amount of resources while Eclipse prepares to launch the projects.
Eclipse shows this status message:
Verifying launch attributes...
At 57% completion, Eclipse hangs for several minutes before finally launching the run configuration. Once launched, the project runs fine and without a problem.
I found this blog article that suggested to clean the local workspace, but that did not solve the problem, especially considering the author is using Git and I am not.
I am only using the latest m2e maven plugin, with the latest version of Eclipse.
What is causing Eclipse to block when launching these run configurations, and how can I fix it?

I had the same symptoms. I could fix it by adjusting
Eclipse -> Preferences -> Maven -> User Settings
My maven user settings file was stored on a remote folder. After moving the file to a local disk, the test now start instantly again.

I know this is a rather old question, but I've been having this issue for a while now and none of the solutions found online seemed to work:
Disable IPv6: didn't work
Disable Ivy classpath resolution: not applicable
Moving the maven settings: not applicable
Delete src classpathentry's from .classpath: this removes all source folders from Eclipse
I did eventually found out (somehow) that having duplicate .classpath files in your workspace can cause serious issues. When importing a multi-module maven project you can easily do this by importing all your modules and your master module (the pom-type module). Doing so, you effectively import everything twice. Closing this master module in Eclipse solved the issue for me.
Another workaround would be to not rely on m2eclipse and to use mvn eclipse:eclipse and then import your projects as an 'existing project'.

This could be caused by duplicate / erroneous entries in the project's .classpath file. These entries are not necessary, as the maven plugin will take care of properly setting the classpath to launch your project.
To prevent Eclipse from hanging, open all of the referenced projects' .classpath files, which should be in the root directory of the project.
Remove all of the entries who have src as their kind attribute value.
For example:
<classpathentry kind="src" path="src"/>
Once all of these entries are removed, Eclipse will now launch your project instantly.

Unfortunately the progress information of the launching in Eclipse is not very accurate. The value of 57% is where all the hard work happens (see e.g. bug 354338).
If you are launching an Eclipse Application or JUnit Plug-in Tests, make sure you have the following plug-ins in your target platform:
org.junit
org.eclipse.jdt.junit.runtime
org.eclipse.jdt.junit4.runtime
org.eclipse.pde.junit.runtime
Otherwise Eclipse will search the whole p2 cache (in my case over 6000 plug-in jars, takes > 5min) for those plug-ins.

I know this is a very old thread, but I just ran into it, and wanted to let anyone who sees this know how I resolved it; maybe it will help the next person. I switched to a new computer at work, and because I was lazy, I just copied my local Maven repository (%UserProfile%.m2) from the old computer to the new computer. After running into the "Launch Attributes" issue and trying everything else, I moved my local Maven repository to another location so that eclipse would be forced to rebuild the local Maven repository. This pretty much fixed the problem; while I sometimes have an occasional delay of 2-5 seconds when launching, it is a big improvement over the 30-90 seconds it was taking previously. Happy coding.

I found this way to avoid 'verifying launch attributes... 57%' in Eclipse-Luna-SR2
have the launch configuration and the main class in different projects
delete the following line from the launch configuration:
<stringAttribute key="org.eclipse.jdt.launching.CLASSPATH_PROVIDER" value="org.eclipse.m2e.launchconfig.classpathProvider"/>

With eclipse 2018-12 I had a delay of about 10 seconds at "57%, verifying launch attributes" for every start of a main class or a junit test. I used the windows tool "procMon" to identify about 500.000 failed accesses to jars in this period that I don't have in my classpath. I found those jar references inside the Manifest "Class-Path" entry of many jars I use.
After removing the Class-Path entry from all jars the delay now is only 1 second!
Some jars were signed. Then I had to remove the signature files (META-INF/*.SF|*.DSA|*.RSA|*.EC) from the jar, too.

One thing that makes a huge difference is how you tell Eclipse what tests you want to run.
When specifying the project name, our tests could take more than 5 minutes to be discovered (the 57%).
If we rather specify the directory containing the test source files, we are down to less than 30 seconds.

java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file "name of class"

I know this question may seems stupid since i cannot give a lot of infos about it, but I think that the problem has to be some kind of bug...
I have written a java program whith NetBeans 7.1, which now gets me this error when trying to run. 10 mins ago it was perfectly running, and i have changed nothing to the class the error refers to
Could this be some kind of NetBeans error? Maybe it is a well know problem?

It also got this exception in NB 7.2
'clean an build' and restarting NB didn't work
updating NB with the latest updates and performing 'clean and build' also didn't work.
So i renamed the cache directory:
c:\Users\userabcd\AppData\Local\NetBeans\Cache\7.2\index\
started NB, waited for it to finish 'background scanning' and pressed 'Debug project' and voila. The cache gets corrupted every once in a while :-/

EDIT: Added Solution B below.
Solution A:
Project Properties
Build >> Compiling
un-check: Compile on Save
Clean and Build
Notes A:
If you leave Compile on Save un-checked, you won't have this problem any longer for this project.
If you enjoy the benefits of the Compile on Save feature, you can re-check the option after you clean and build, and continue work on your project as normal.
Compile on Save is meant to save time by constantly recompiling your .java files into .class files in the background as you save changes to your source code. That way when you build or run your project, most of the compiling work has already been completed allowing you to run and test your code quickly, even for large projects.
NetBeans uses some fancy caching and versioning to avoid having to recompile your entire project every time you save a file. That's why the other solutions listed here will often work; they are ways of defeating this caching-and-versioning system when it occasionally fails, as it has above.
Solution B:
Create empty folder e. g. C:\Temp\mine
Create a new shortcut for NetBeans
with command line parameter in Target:
"C:\Program Files\NetBeans 8.2\bin\netbeans64.exe" --userdir "C:\Temp\mine"
When compile errors occur
(ClassNotFoundException, MethodNotFoundException, etc...)
delete C:\Temp\mine\var\cache
Notes B:
You'll lose all your NetBeans settings the first time.
Much easier to solve future compile errors caused by caching bugs.
Allows running multiple copies of NetBeans, one per userdir.

I got also this exception. My solution was:
edit and save mentioned class (.java file)
clean & build project
deploy to tomcat server

I just had this happen to me with Netbeans 7.4 Beta.
Things I tried:
Restarting Netbeans.
Clean and build.
Shutting down netbeans, renaming the cache dir, starting netbeans and waiting for scanning to complete.
What worked for me:
Making the source file writable and saving a meaningless change (inserting a space).
I don't know why any of the other steps didn't fix the error. Maybe it would have worked if I had done a clean and build after renaming the cache dir?
Its a very frustrating situation to be in - Hopefully this helps someone (perhaps a future me?).

The JDK says for ClassFormatError:
Thrown when the Java Virtual Machine attempts to read a class file and
determines that the file is malformed or otherwise cannot be
interpreted as a class file.
Perhaps a class file has become corrupted. I am going to do the standard IT support statement.
Have you tried restarting NetBeans?
Hope that helps

Got right the same thing with Netbeans 7.1.
Working on a project that works fine for several months.
Now I changed a bean which gets persisted with javax.persistence and now this exception got thrown. Reverted my few changes, clean and compile the project, reboot the whole system: still exceptions.
The curious thing about it: the generated .war works perfectly in a Tomcat at another machine.
UPDATE:
Today I got the same problem again and I couldn't recall how to solve it, but I found this post again. ;)
After a half hour I found the solution: Just change value of the property serialVersionUID, redeploy the app and then you can change the value to its original value and redeploy again -> working.
Seems like Tomcat is holding that class somewhere deep inside – deleting working directories didn't led to success.

Eclipse is freezing itself before getting started

I've been trying to open Eclipse to start my work today, and it freezes everytime during load.
My Eclipse is Helios. Someone told me I should remove a file called .lock from .metadata folder, but still didn't work.
Does anyone have any idea of how do I "melt" this thing up?
ps: I opened it yesterday with no problems.

Have you already tried to start Eclipse with a -clean parameter? Sometimes this can resolve some issues..

I would suggest a (big) problem with a plugin in Eclipse.. because project plugins or runtimes will execute later.
Create a new workspace and repimport your projects from your old workspace. If you have a vcs, you can re-checkout them.

Start it with the -clean option.
It should take a bit longer (depends on your eclipse configuration and workspace, but if nothing is really broken, it will get it to work).

I believe something is wrong with your workspace. I typically remove current and create new one in such case. It usually takes up to 5 minutes (if I have to add 20 projects). In most cases it takes less.

I have experienced something similar when launching Eclipse after having to force close it for some reason.
If it always hangs when loading the SVN plugin — like in your screenshot — it is likely to be related to that. In this case I suggest the following:
back up your current workspace
launch Eclipse with the -data command line argument to specify a different workspace folder
if Eclipse starts up successfully, try to import your projects from the original workspace or even better from SVN

Eclipse does not refresh project files in package explorer view

Today I see a strange behaviour of Eclipse 3.5.2 for the first time in 3 months.
First, when I run a main function, it runs a previously compiled version. Let's say I press Ctrl+F11 in the window with an open java class and existing main function. Usually it rebuilds the class and runs a new version. Today even if there was a compile mistake, it would run fine. So I guess it does not recompile the class.
Next, more strangely, if I intentionally make a mistake in the code and Eclipse underlines those lines in red, still the project Explorer does not mark them as containing errors. They remain of grey color if there were not any errors.
First I did not know how to solve this problem. I tried to reopen the project, restart Eclipse and finally reboot the OS. After the tenth attempt, after rebooting, Eclipse said that all project's files are "OUT OF SYNC with the file system". When I pressed "Refresh" - F5 on a project's header name in Project Explorer it finally marked all the files with errors as containing errors and running the main function gave the desired result.
An hour of my work passed and this happened again , with the other project. All the same. No marking of files as red, running no matter what old version of class with no compile errors.
And since Eclipse does not tell that files are out of sync, simply pressing F5 on a project cannot help.
What can you suggest?

When you select a project in the Project Explorer view and press F5, Eclipse should traverse the entire directory tree for the project checking that all files and directories all in sync. It does for me ...
The only thing I can think of that would cause this not to work is if you have file system timestamp anomalies. For example, if a file in the file system is updated but the file's last-modified shows that it was updated in the past. This kind of thing can happen if your machine's system clock is moved backwards or forwards at an inconvenient time. If you think this might have happened, try closing all projects, restarting Eclipse and doing another F5 refresh.
(I used to run into Eclipse synchronization issues a lot, but I put that down to a combination of flakey plugins and doing builds from the command line. Either F5 or Project>Clean usually works for me.)
It is also worth checking that you haven't turned off "Build automatically"; see https://stackoverflow.com/a/2818290/139985. This is not a "refresh" problem, but it would be easy to confuse it with one.

Is Build automatically on? (Menu > Project > Build automatically)

It happened to me because there was a cyclic dependency between two projects. Each project had the other on its build path.

Solution: Reimport the project
It happened to me when checking out a new file from svn in explorer. Eclipse could not find the new file for some reason.
I tried refreshing the project(F5) and Project > Clean and build the project(Project > Build All) none of these worked for me.
So I deleted the project from the Project Explorer view(Not from hard disk). Make sure you unselect "Delete project contents on disk(cannot be undone)" checkbox and save any unsaved changes before you do this.
Now reimport the project using File > Import option. That should work in most cases.

If you use gradle, or something similar, instead of reimporting a project you can just regenerate the project files (gradle eclipse for example), and then you can refresh the project. Less cumbersome than deleting and reimporting.