Related
When ever I try to launch my eclipse I am getting the following exception an its not coming up.
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
Need help.
Thanks.
The /configuration/config.ini file should contain org.eclipse.core.runtime#start in the commaseparated osgi.bundles property. Here is the default osgi.bundles property, maybe it was (accidently) changed during some upgrade:
osgi.bundles=org.eclipse.equinox.common#2:start,org.eclipse.update.configurator#3:start,org.eclipse.core.runtime#start
You can if necessary override it by setting it as VM argument in /eclipse.ini:
-Dosgi.bundles=org.eclipse.equinox.common#2:start,org.eclipse.update.configurator#3:start,org.eclipse.core.runtime#start
I have had the same problem, and here's how I solved it: I added the plugin "org.eclipse.core.runtime" in the "plugins" section on the "configuration" tab of the .product editor. I set it's start level to default and auto-start to true. I removed other plugins. My reasoning was this: Eclipse is complaining that the org.eclipse.core.runtime isn't started, so let's make sure that it does start, and that it's the only plugin that's starting.
My application ran fine after I did this. I then inspected the config.ini to see what changed, and saw that org.eclipse.core.runtime was now changed to org.eclipse.core.runtime#start. This is consistent with BalusC's suggestion, I just did it from the .product editor.
Adding my two cents for those searching for "Ensure that the org.eclipse.core.runtime bundle is resolved and started":
Adding "arbitrary" bundles to the list of bundles just because it seems that they are missing is not always the best solution. Sometimes it can get quite frustrating, because those new plugins might depend on other missing bundles, which need even more bundles and so on...
So, before adding a new dependency to the list of required bundles, make sure you understand why the bundle is needed (the debugger is your friend!).
This question here doesn't provide enough information to make this a valid answer in all cases, but if you encounter the message that the org.eclipse.core.runtime is missing, try setting the eclipse.application.launchDefault system property to false, especially if you try to run an application which is not an "eclipse application" (but maybe just a headless runtime on top of equinox).
This link might come in handy: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html, look for the eclipse.application.launchDefault system property.
try running it from the Command Line as:
>eclipse -clean
Or, you could run it using java instead of the default javaw, here:
>eclipse -vm c:\jdks\java_1.5\jre\bin\java.exe
I got this problem with Mac OS Lion, after transfer OS/Data from an older machine to a new one.
Solved deleting the old eclipse folder (which I have in Applications folder) and copy eclipse folder again (same version, same unpacked zip file, no changes).
The accepted answer above is correct, except for it's not completely clear.
You need to add the following line to the bottom of the eclipse.ini file:
-Dosgi.bundles=org.eclipse.equinox.common#2:start,org.eclipse.update.configurator#3:start,org.eclipse.core.runtime#
For me installing the jdk 1.8 solved the issue.
This error happen cause you deleted the config.ini file while you deleted the plugins. So, when it can not find configuration in config.ini when eclipse lauching， then it use default configuration which is not fit with your os. The following steps solve you problem:
Delete setting in configuration folder.
create a new config.ini file.
copy following setting and save:
osgi.splashPath = platform:/base/plugins/org.eclipse.platform
osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
eclipse.product=org.eclipse.sdk.ide
osgi.instance.area.default=#user.home/workspace
eof=eof
restart eclipse.
For me, what eventually did the trick was adding -clean at the start of eclipse.ini
In the Windows environment, running Eclipse as Administrator solved the issue. (Right click>Run as Administrator)
if you face this in 2021 or later better check that you have jdk 11 installed and is configured correctly. I downloaded the latest eclipse-jee-2021-06-R-win32-x86_64 and on running i got this issue. I checked the java version on my system and it was: 1.8 I downloaded the latest OpenJDK 11 configured it (JAVA_HOME in an environment variable and <JAVAHOME/bin entry in PATH environment varaible>) and the issue is gone.
I've been downloaded the "SDK ADT Bundle for Windows" adt-bundle-windows-x86.zip to "Documents and settings\myusername\My Documents\Downloads" and tried to unzip to a folder c:\Android
When all seems to be decompressed I saw some files where missing in the destination folder including the eclipse.ini.
I solved this by renaming adt-bundle-windows-x86.zip to a short name adt.zip, moving it to c:\ and repeating the decompression.
All is due to bad treatment of long file-names in windows
For those coming here having tried to run the application from a Windows command line, or batch file, and possibly those receiving the stated error message in a Rational Clear Case log file:
The PATH is very important to the processing of config files, and the following was required for me:
START "Clear Case" /D"C:\Program Files (x86)\Rational\ClearQuest\rcp\" "C:\Program Files (x86)\Rational\ClearQuest\rcp\clearquest.exe"
note the /D option.
Adding to a well-populated page:
I had this come up when I tried to move the eclipse installation to a different location on my drive. I tried grepping for the old directory path in the package, thinking perhaps I could fix it with sed, but the path was written in multiple formats and even found in binary files. I gave up, made a fresh install, and re-installed my plugins.
(Here's a question about moving an eclipse installation, but it didn't give me enough to make it work.)
I tried all the methods proposed here. I finally deleted the eclipse folder, extracted it again and now everything works perfectly.
I received this message trying to run STS 3.7.0 on java 6 jdk, after pointing to java jdk 7 (-vm param in STS.ini) the issue disappeared.
I got this problem somewhere on the logs and I saw that my java version was not 1.8 somehow. Upgrading it again to 1.8 solved my problem.
Download new eclipse or spring suite and open old workspace into new eclipse or STS
shawn: My eclipse have started when I extended bundles:
osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start, org.eclipse.equinox.ds#start, org.eclipse.equinox.event#start
If none of the above answers works for you, try the following:
Get the "org.eclipse.equinox.simpleconfigurator" and the "org.eclipse.update" folders found under the "eclipse\configuration" from a working Eclipse instance (can be the stock Eclipse downloaded from their website) and replace them in your Eclipse installation directory.
This fixed it for me.
I tried all the answers above, but none of them worked for me, so I was forced to try something else. I just removed the whole package with settings org.eclipse.Java and it worked fine, starts again like before and even keeps all settings like color themes and others. Worked like charm.
On Linux or Mac go to /home/{your_user_name}/.var/app and run the following command:
rm -r org.eclipse.Java
On Windows just find the same directory and move it to Trash.
After this is done, the settings and the errors are deleted, so Eclipse will start and re-create them with the proper settings.
When Eclipse starts it will ask for the workspace directory. When specified, everything works like before.
The only thing that worked for me was to run Eclipse using JAVA from the command line.
C:\Development_Tools\eclipse\java-2021-092\eclipse>java -jar plugins/org.eclipse.equinox.launcher_1.6.300.v20210813-1054.jar
This was executed from the folder where eclipse.exe resides.
I made my own shortcut for this and now use that shortcut instead of the one produced when installing Eclipse from their website.
in my opinion, if after trying all solution nothing wors then simply delete eclipse folder from your C://use/{pc}/eclipse and then again install the same eclipse . You will get all your data no need to worry.
This happens because of unexpected shutdown of your eclipse
delete processcenter.ini at location similar to:
C:\IBM\IntegrationDesigner\v8.5\iid
and then once IDE comes up, go to windows preference and put in the correct URL.
I can import a sample app project, try to build it and I keep getting this error. Not always the same file but a new temp file each time. I've tried several different samples. I've been programming for 30+ years and feel completely clueless. Only clue seems to be the Windows Task Manager shows 99% to 100% CPU usage when it gives the error and ends the build.
Do This
File -> Invalidate Caches / Restart.. -> Invalidate/ Restart
When this happens to me on Windows 8, I open the task manager
and simply kill all the instances of "openjdk platform binary"
Just clean the project and have a run ! It would work ....
Choose app instead of DefaultPreview. Now if you build, then you should not see this issue.
Invalidating the IDE cache is NOT enough.
To delete the folder app\build we should first stop locking process - OpenJDK Platform binary.
Delete the folder app\build
Invalidate Caches / Restart...
Context: Using Coroutines in Android Instrumented Test.
GL
I have the same issue's.Even I tried all the solution mentioned here it didn't work.Even I can't delete the signin file as running android studio administrative mode.I see a notification at bottom right side of the IDE update gradle pluggin.So update gradle pluggin usually worked for me
Kill task "openjdk platform binary" works for me
Restart of Android Studio with cache invalidation doesn't help.
As others said, we should delete a <module>\build folder. Because a file is locked by OpenJDK Platform binary, we should stop this process in Task Manager (or unlock the file via LockHinter).
I had the same problem and in my case it is due to multiple Java Run times (JRE's). Try switching between JRE's in android studio or use only one Java runtime.
Hope it fix the problem. Happy Coding..
Invalidate Caches / Restart doesn't work all the time and it's not the better idea to close the whole Android Studio just we couldn't figure out what process was using it.
Please follow the below steps to figure out which process is using your file.
You can use the Resource Monitor for this which comes built-in with Windows 7, 8, and 10.
Open Resource Monitor, which can be found
By searching for Resource Monitor or resmon.exe in the start menu, or
As a button on the Performance tab in your Task Manager
Go to the CPU tab
Use the search field in the Associated Handles section
When you've found the handle, you can identify the process by looking at the Image and/or PID column.
You can then try to close the application as you normally would, or, if that's not possible, just right-click the handle and kill the process directly from there.
Ref : https://superuser.com/questions/117902/find-out-which-process-is-locking-a-file-or-folder-in-windows
try to delete the file (the folder inside builder message)
the message will contain process name ( i dont remember the name)
find the prcess in task manager and stop it
I had 2 jre's installed when I installed android studio. Uninstall the one that you find from control panel and that is located something like c:\program files\java etc.
On the next opening of android studio 4.0 + it will fallback to "C:\Program Files\Android\Android Studio\jre" and the process lockdown after each succesfull build will stop
If the error is recurring, you can try a file leak detector to determine what part of the gradle process is holding your files. As suggested here,
Download file leak detector
Check with resmon what process is holding on to the file
Depending on where the file is locked, do the following:
Android Studio: In studio, go to Help → Edit custom VM options and add the following line:
-javaagent:path/to/file-leak-detector.jar=http=19999
Gradle: Add to your gradle.properties file the following line:
org.gradle.jvmargs=-javaagent:path/to/file-leak-detector.jar=http=19999
When the problem occurs again, open localhost:19999 in your browser and search for locked files.
In my case, I found out that a file was held by AspectJ compiler/weaver (ajc):
#115 C:\Users\me\StudioProjects\myapp\app\build\intermediates\compile_and_runtime_not_namespaced_r_class_jar\debug\R.jar by thread:Execution worker for ':' Thread 3 on Mon Oct 19 18:41:06 BST 2020
at java.util.zip.ZipFile.<init>(ZipFile.java:156)
...
at org.aspectj.tools.ajc.Main$run.call(Unknown Source)
I was running it directly from Gradle:
new Main().run(args, handler)
I don't know if it's possible to make ajc release the files. So I resolved my issue by running it in a separate process. I added a new configuration to get aspectjtools onto classpath:
val weaving: Configuration by configurations.creating
dependencies {
weaving("org.aspectj:aspectjtools:1.9.6")
}
And instead of the above code, I did:
javaexec {
classpath = weaving
main = "org.aspectj.tools.ajc.Main"
args = arguments
}
For those which are still searching for this answer in 2022, remove the build folder and rebuild...
Had the same on Windows 10, it was resolved by closing all "Command Prompt" (cmd) windows 🤷♂️
Terminating "OpenJDK platform binary" from Task Manager then deleting src/build and finally rebuilding the project should make it work.
Above suggested solutions may fixed this error but they are time consuming so the best solution to fix this problem is open command prompt and run the following command.
taskkill /im java.exe /f
In my case, deleting the /.gradle/ directory and rebuilding resolved the issue.
If you are using External Emulator:
Restarting Android Studio with cache invalidation doesn't helped.
The file that caused the problem is being used by the emulator and if you are using an external emulator (BlueStacks) like me, restarting Android Studio will not help. I restarted the emulator and the problem went away.
It happened me many times while building or Cleaning the Project
The solution is simple:
Open the Specific Directory
Close the Android Studio
Delete the particular Directory
Now run the Android Studio
So, I made some changes to my build.gradle(app) file and android studio gives me this error (open the image in new tab for better viewing):
My build.gradle(app) file (this is not the edited file, I deleted new lines of code and still no luck/solution.):
Everything was quite working well until I made some changes in the build.gradle(app) file, but then I deleted those new lines of code and android studio is still keep giving me the error.
The error relates to the compile 'com.google.android.gms:play-services:8.3.0'.
I have tried deleting/renaming those png images inside the stated folder,but then when I rebuild the project, the png images are automatically downloaded.
My build.gradle(project) file contains classpath 'com.android.tools.build:gradle:1.5.0'. I want to know what causes this error, and how to fix it? Many thanks.
You could also try changing your build directory for your project since that is where most of the path issues will arise. In your root build.gradle file
allprojects {
buildDir = "C:/tmp/${rootProject.name}/${project.name}"
repositories {
...
}
}
Android Studio will pick up on the change and still show your new build location in the Project view. It's a lot easier than moving your entire project.
EDIT
While Windows 10 Insider Preview now offers the ability for allowing for longer file path limits these limits currently are only actually accessible to apps which have specifically enabled support for longer file paths.
At the current time, it appears that these applications with the extended path enabled seem to be only apps that are installed via the Windows Store.
At the current time, Gradle does not and potentially cannot have this option enabled to utilize the enhanced NTFS file path length.
I just ran into the same issue. I don't know a fix for your exact problem, but I found a work around; I see your project has a deep file path hierarchy. Why not just move your project up from a lower level?
Ex: C:\Projects\YourProject
That fixed the problem for me.
Cause of problem : 'C:\users...\commom_google_signin_btn_text_dark_normal.9.png' icon path length is greater than 240 character which exceeds Maximum File Path Length Limitation of Windows OS.
Solution is : Move your project into top directory like 'C:\your_project' or reduce length of your project name.
Here is windows path limit chart
As a very solid alternative to actually moving the project I'd suggest using a hard link. The syntax of that would be like this
mklink /J C:\AndroidProjects\ProjectName C:\MyVeryVeryVeryVery…VeryVeryVeryLongPath\ProjectName
Now you can work on your project in C:\AndroidProjects\ProjectName, and have the changes right where your project is supposed to be.
I agree with Vladimir Dimov answer.
You must choose the short path for your project as it is mentioned that the file path should be below 240 characters on Windows.
This link helps me out : http://www.feelzdroid.com/2016/01/android-studio-error-file-path-too-long-windows.html
As an addition on lodock's answer, you can use a hash on the project path if you have lots of projects with the same name:
import java.security.MessageDigest
def hashString(String s){
MessageDigest.getInstance("SHA1").digest(s.bytes).encodeHex().toString()
}
allprojects {
buildDir = "C:/AB/${hashString(projectDir.getAbsolutePath())}"
}
Shortening project paths is really a bit of a hack, Ivan Neeson's response seems the way forward.
If you are lucky enough to be using Android Studio then you will see a useful error message about file length.
If however you hit the same issue doing a command line ionic build all you will see if some kind of crunch error for a png file and it's not so obvious.
The real issue is Google Play Services having such extravagant filenames such as common_google_signin_btn_text_light_normal_background.9.png which is simply not Windows friendly. Dump that inside an Android build and the path explodes outside our control to platforms\android\build\intermediates\exploded-aar\com.google.android.gms\play-services-base\10.2.1\res\drawable-xhdpi-v4\common_google_signin_btn_text_light_normal_background.9.png
Have look at this http://feelzdroid.com/2016/01/android-studio-error-file-path-too-long-windows.html. Solution is too simple keep path of folder less then 240 characters.
Make sure you will have less then 240 charters in the path
I found this issue when I have two repeated folder in same like,
E:\project-one\project-one
and when it has a large length of folder name like,
E:\project-one-with-very-big-name
To avoid this problem make a folder of project simple and short.
You Should Have To Keep Your Project Directory As Less Deep As Possible
For Example:-
D:/AndroidWorkSpace/ProjectName
Because Gradle Support Only 240 Character length of Project Path
Thanks
You can use NTFS junction point to create shorter path to your project.
To read more about Junctions read this :
Hard Links and Junctions
A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer. Otherwise, junctions operate identically to hard links
For Windows users:
You might be tempted to create a network share to the project root folder and then map to it. This technique will shorten the overall path length but will cause problems for Android Studio due to the difficulty in detecting modified files. A better solution is to use the windows subst command. Here is an example script to circumvent the problem. Tweak names as necessary and modify to point to your project and install directories.
File: launchAS.cmd
subst P: "C:\private\java42\ide\42g\workspaces\AndroidStudioProjects"
cd "C:\private\java42\programs\android-studio-base\bin"
start studio64.exe
The above commands will create a P: drive and map it to the project root folder. This will reduce the overall path length to project files and might give you some relief for the too long path name problem. Use P:\ as you would have used the long root name when opening projects.
To remove the mapping use command: subst P: /d
I was facing the same issue , my project is in C drive and it is in deeper path location, What i did I just moved my project to other lower deep path location and it works, you just change the project location and project should not be in deep location hierarchy.
I had a different experience with this problem. First I has this error but then i noticed that my previous projects in the same directory were opening. This is the path:
C:\Users\koralis\Documents\extraction\Ex_Files_Android_App_Dev_LDS_Upd\Exercise Files\Ch01\01_06\ImageAssets
Surprisingly, I updated that gradle version to
'com.android.tools.build:gradle:3.2.1' from 'com.android.tools.build:gradle:2.0.0'
This solved my problem.
I do have a multi-module project with a library project in a different root path. As illustration you can imagine something like this:
/projects_home/projects/app_root
|--app/
| |--build.gradle
|--build.gradle
|--settings.gradle
/libraries_home/libraries
|--libA
|--build.gradle
In my settings.gradle file I am able to set the absolute path to the library project utilizing the projectDir attribute. This works just fine within the console as well as with Android Studio.
But if I try to use an environment variable it stops working with Android Studio. The settings.gradle for the example above would look like this:
include ':app'
include ':libA'
project(':libA').projectDir = new File("$System.env.LIB_ROOT", '/libraries/libA')
If I build with the graddle wrapper from the console, it still works. But AS stops working with the following error msg:
Gradle 'app' project refresh failed:
Configuration with name 'default' not found.
If I unset the environment variable, the build on console fails with the same msg:
* What went wrong:
A problem occurred configuring project ':app'.
> Configuration with name 'default' not found.
Therefore I guess that AS is somehow not be able to access the environment variables set with my ~/.bashrc
Does somebody of you maybe know a way how I can make AS aware of my environment?
Android Studio does read the environment variables. You can prove it by launching Android Studio from the shell in which those env. variables being specified instead of from X-window dash board.
The reason you did not have those variables is the X-window environment you were using did not read $HOME/.bashrc which contained those variables. This makes sense because bashrc is for Bash not X.
Assuming you are using GNOME or Unity, to launch Android Studio with those environment variables being specified, just modify the .desktop file of Android Studio (e.g. ~/.local/share/applications/android-studio.desktop):
Find this line:
Exec="/home/username/tools/android/android-studio/bin/studio.sh" %f
Change it to:
Exec=env LIB_ROOT=/libraries_home "/home/username/tools/android/android-studio/bin/studio.sh" %f
Note:
This modification just prepend env LIB_ROOT=/libraries_home to the original command. You must replace username with your own user name.
Update
If you have any questions, please leave a comment instead of editing the answer directly.
On Macs, Android Studio does not read environment variables for use in Gradle apparently. I believe this is the cause for confusion in the answers here - maybe it does on Windows.
In order to get Android Studio to read environment variables, I run the application from the command line:
> /Applications/Android\ Studio.app/Contents/MacOS/studio
The other answers here offer solutions other than using environment variables. For my situation, I'm using a library I didn't write that requires the use of an environment variable, and I'd rather not edit their code so it's easier to update later.
EDIT: And, I have a dock icon to launch Android Studio this way:
OSX: Add Dock icon for dedicated Terminal command explains how.
Android Studio doesn't read environment variables, so this approach won't work. Also, using the projectDir scheme in settings.gradle will probably cause problems. Android Studio has a limitation that all of its modules need to be located underneath the project root. If you have libraries that are used in multiple projects and they can't be placed under a single project root, the best advice is to have them publish JARs or AARs to a local Maven repository that individual projects can pick up.
Despite the answer from Scott Barta is correct, I realized there is a way to solve my problem and wan't to share this in case somebody else has the same requirement.
I am now using the gradle.properties file do define and use gradle properties instead of system properties. The documentation of this feature can be fined in the user guide
The solution to my original question now looks like this:
$USER_HOME/.gradle/gradle.properties:
LIB_ROOT=/libraries_home
The settings.gradle file has to be modified to use the gradle property instead of the system property:
include ':app'
include ':libA'
project(':libA').projectDir = new File(LIB_ROOT, '/libraries/libA')
This works fine for me, headless as well as with AS.
Some more words regarding the fact that I am working with modules which are not placed underneath one project root. Till now it looks like AS is not complaining about this. But I just started working with this structure and it may be that I will run into problems later. What I like about this is the more flat representation in AS which is more like I am used to have it with Eclipse.
What is also described in the user guide, is to set system properties with the gradle.properties file. I tried this also, but I did run into the same problems with AS using environment variables.
It works for me with the following steps:
Set your variable in Windows
Reboot
reach it in gradle build: System.env.MYVARIABLE
I faced the same issue in apple laptop after the Android Studio Bumblebee update. This seems to be happening due to some permission issue with the Android Studio.
The workaround is to add missing flag:
chmod +x /Applications/Android\ Studio.app/Contents/bin/printenv
You can check this issue tracker for more details.
You can set environment variable by appending:
-DYOUR_VARIABLE=variable_value
to ~/Library/Preferences/AndroidStudioX.X/studio.vmoptions that you can open by selecting Help -> Edit Custom VM Options... from Android Studio menu.
And then you can use it like:
System.env.YOUR_VARIABLE
in build.gradle or settings.gradle.
MAC OS Update
I confirm that I have Environmental Variables working on Mac OS Catalina
You just need to set it in the shell you are using. I was using zsh, and was trying to set ~/.bash_profile, so it wasn't working.
Example:
ZSH Profile
If I change some code, save, and Run, it runs the last version of the program, not what I just saved. The only way I can make it update is if I Clean the project, Build the project, and then Run the project. Is there some way to avoid this tedium?
I spent some time create two dummy projects (one Android and one Java) and have a play with it, and finally come up with a workaround which is not used very often but able to solve your requirements.
First, I will explain your question a bit more (based on my understanding and what I have tried) so that other people can have a more clear understand about what is happened here.
According to the conversation in comments:
could you tell me what you have in following setting: project->properties->Builder ? – Sudar Nimalan
#SudarNimalan: I am not sure this is what you are asking, but: there's text that says "Configure the builders for this project", and under it is a single option, "Java builder", which is selected (checked). – shino
for android project, there should be, "Android Resource Manager", "Android Pre Compiler", "Java Builder", "Android Package Builder" in this order, chould you add those and try? – Sudar Nimalan
#SudarNimalan: I owe you an apology; I do have those four components. My "project" is split into 4 projects - "core", "core-android", "core-desktop", and "core-html". It's a little weird because I set it up with the libGDX project setup UI, and I was looking at the 'core' project when I answered your question. My 'core-android' project has all four (in that order), and it is the one that has the problem in my question. – shino
Scenario:
You have 4 project:
core: a regular java project (common pure java code here)
core-android: an Android application project.
core-desktop: not related to question so ignored.
core-html: not related to question so ignored.
The core-android project has dependency on core project, by adding core to core-android's build path (Properties -> Java Build Path -> Projects -> Add ...) and export list (Properties -> Java Build Path -> Order and Export).
Problem (Not Really):
Change some code in core and save it, run core-android, eclipse install last compiled apk, not the new one with change.
Reason:
The is the expected behavior, the way you used to reference core project in core-android only create a weak link (or something sort of) between core and core-android, the core-andorid's auto-build script doesn't aware any changes made in core. You have to clean the project (only need clean core-android project) so that Eclipse can delete the existing apk (under bin directory) and re-generate the apk (with the latest code changes from core).
See Xav's comments below, Android SDK tools should aware changes from plain Java project under project build path, and it does not behaviour this feature normally at the moment.
Note that if core is an Android Library project, then there is no problem and your core-android project will aware any changes in core project (java code, android resource and etc), if core is only used in core-android, this could also be a workaround: turn Java project core into Android library project.
Workaround (Eclipse Link Source):
There is another way (not commonly used) for adding soft link between projects:
First, you need remove core project from core-android's build path, this will also remove it from Export and Order list.
Right click core-android, choose Build Path -> Link Source ... Add ../core/src as Linked Folder Location and src-lib1 as Folder Name,see screen screen in the end.
This create a symbolic link src-lib1 under core-android in Package Explorer windows point to core's src foder, in the file system, you still have two separate project folder. Now if you change some code in core and run core-android, Eclipse will build and install latest apk. No need to clean core-android project.
Link Source Window:
Final look in Package Explorer:
You should always consider the normal approach as first option, after all, manual clean project is not a big deal compare to the unusual approach I described above.
Please follow this steps..
1. Project--> Build Automatically been checked??
2. Please following setting: project->properties->Builder like that?
Check below image.
And Also Check Below Settings.
Also Check Below Image
IF problem continues then please Update your ADT & SDK.
Hope it works for you .
Navigate to Windows->Preferences->Android->Build. Make sure that the checkbox "Skip packaging and dexing..." is NOT checked.
The Problem is the In your Eclipse, go to Project Properties - Builder, There is one CheckBox with AndroidPackageBuilder that is required to be Checked True. Now everytime you will do any changes in you project that will be reflected in your build and the Compiler will never say that
"Application Already Deployed, No need to Reinstall"
This will work evenif you dont have selected Build Automatically, Because everytime you run by clicking Run icon or Ctrl+F11 that will first Build the Project and Then Run it. So The requirement is just to Enable the Android Package Builder
You won't believe how easy and silly is the solution
On Eclipse,
go to Window-Prefences->run/debug ->launching
And then, on Save required dirty editors before launching :
choose the Prompt option,
Apply and OK