How install old ADT13 in Eclipse - android

We do have lots of problems with our Android Apps when using SDK14/ADT14. Currently we can't build none of our complex apps with lots of libraries and dependant projects (Resources are not updated even after Clean, Refresh, Forced Save, ...). We would like to go back to SDK13/ADT13.
SDK13 is in our backup repository. But we don't have the ADT13 plugins.
How can we direct Eclipse to download the old ADT13 plugins?
Many thanks in advance.

I had to do this recently as well. Fortunately there's a hidden cache of old ADT versions, here's the link for the previous ADT release:
http://dl.google.com/android/ADT-12.0.0.zip
Then inside Eclipse you go to Help -> Install new software -> Add... -> Archive ... -> choose the downloaded zip. FYI: Unfortunately, you can't (or at least, I couldn't) revert to the previous SDK Manager and Tools version so easily (it insisted on getting itself upgraded before downloading the SDKs), I had to use an old copy of the folder I had lying around. Since you have SDK13 in your repo, you should be good to go.

You need to make sure that you've updated both the SDK AND the ADT plugin in Eclipse - I forgot to do the latter and had the problems you've described.
SDK14/ADT14 introduced a lot of changes - the old ADT won't work with the new SDK and the new ADT doesn't work with the old SDK.
If you've done both and it's still not working then moyshe's link takes you to the relevant to stuff to download (just uninstall what you have already and install the older versions)

Is your issue similar to this: http://code.google.com/p/android/issues/detail?id=21201
Basically each time I open Eclipse, I have to remove all library projects from all projects using them, apply changes. Then re-add them manually. Then I can start working!
It's very probable that it's related to http://code.google.com/p/android/issues/detail?id=21031.
This is serious issues and I can't believe no-one from Google has responded yet!

I'm posting this separate answer because of stuff I've learned from the Google Groups threads and my own experiments. I realise it's not a straight answer to the OP's question but I think it's useful here regardless.
ADT14 has changed how Android Libraries are handled in Eclipse. Instead of importing sourcecode (in LIBRARYNAME_SRC folders) it now compiles and brings over .JAR files (in a "Library Projects" folder).
To get my stuff working I built a complete new environment, installed the latest Eclipse/ADT/SDK, Imported my work and worked through all my projects from non-dependant libraries upwards - doing the following.
1 - remove all Android Libraries and 'Apply'
2 - remove all xxx_SRC folders from the Build-Path->Source tab
3 - remove any remaining xxx_SRC folders (should be empty anyway) from your Project.
4 - Add your Android Libraries back in again.
Another relates to Build Path Projects (non-Android ones). Before, ADT did not mind if you had the same Build Path Project in multiple libraries - but it sure-as-hell does now!! It crashes with "UNEXPECTED TOP LEVEL EXCEPTION"s, "java.lang.IllegalArgumentException: already added: Lcom/yourlibrarypath" and "Conversion to Dalvik Format Failed" messages.
This prevents you deploying - to solve it, go through your libraries and ensure that Projects only appear on the Build Path ONCE. I suspect that, previously, ADT actually may have need them duplicated and may even have created this duplication!?
Lastly, you have to ensure that Eclipse builds everything in the right order. Again, this didn't matter before but it's why your projects fail if you 'clean' or change anything. To do this you have 2 choices
1 - rename your projects so that they appear in alphabetical order from 'leaf' to 'root' (e.g. libraries < projects which use them).
2 - In Eclipse, use Windows->Preferences->General->Workspace->Build Order and specify all your libraries, in order. Anything not in that list is built afterwards so only libraries need be mentioned there.
Hope this helps someone

Related

Cleaning ActionBarSherlock creates R cannot be resolved error

I've recently (this morning) updated a bunch of android plugins in my eclipse environment (so I could switch over to Android Studio), however, I decided to return to Eclipse to finish something up. I had to re-import the actionbarsherlock project (4.2.0 library). After I imported, made sure it was running on Android 4.2 and as a library, I cleaned the actionbarsherlock 'library' project. Which resulted in over 200 'R cannot be resolved to a variable' problem.
I've tried all the usual suspects: couldn't find any errors in the res file, tried cleaning, refreshing, closing eclipse in various different orders.
I'm also noticing a new dependency entitled "Android Private Libraries" -- I am not positive it is new from this update, but it could be.
Other information that might be useful:
- there are no gen files (nothing is being generated)
- I also linked it to my Android Project as a library (set to the same API level)
- I've done separate cleans and a clean at once
Any help would be great, I'm stuck on this one and it's driving me nuts.
You have to check the Android Private Libraries in the java build path of the project:
Resolved by updating the API's as well as the tools and everything else I updated this morning. Very weird situation.
In my case I had the wrong Android target. To solve it:
Right click on your project, then Properties, then click on Android and select the correct Project Build Target.
I had Android 2.3.3 and I changed it to Android 4.2.2
I hope this helps to someone.
This problem was stupid(I mean this situation)... and I was using a stupid way to solve it.
update android API & SDK & anything else you can.
Open your library project's Properties window, go to [Java Build Path], [Order and Export]
Use [Up] [Down] button to make sort sequence like this:
After this, it still shows same error, so you have to re-build this single library project again.
Check top menu, [Project], [Clean...]
Clean that single library project, make it auto re-build.
That's how I solve all my library porject's same problem. (ActionBarSherlock, FacebookSDK, SlidingMenu, ViewPagerIndicator)
Sounds like a stupid solution, but just match this stupid situation.
Google, what the hell are you doing ?
In my case I am running 64 bit Linux (Linux Mint) and I had to install 32 bit libraries using sudo apt-get install ia32-libs
After installing the 32 bit libraries I restarted eclipse and cleaned the ActionBarSherlock library and all is good
Are you using the Android support library?
I had this error because I had a different version of the Android support library jar in ABS vs. the rest of my project. Make sure the support library jars you are using are identical in every project.
Strangely enough, this issue gets fixed when I add old flavors of Android SDK build tools: 18.x and 17.x
(For some reason, I uninstalled some of those)

Why is my updated Eclipse / Android setup not building my APK anymore?

I had a working Eclipse setup with 3.6.2 and SDK tools from version 11, and it has been building my main project just fine for quite a while.
For a different project, I thought I needed to upgrade my SDK to the latest and greatest - at this point API 14 (ICS 4.0).
I cannot even reconstruct the steps I went through, but what happened was that my project would seem to build, but I would see that it would say that it was skipping a post-compiler step, and at the end I would have no APK.
I also noticed that it updated my .classpath so that the output path was bin/classes instead of .bin.
Along the way I tried updating my Eclipse to the latest version (Indigo 3.7.1) but this didn't help.
I solved the problem eventually with help from this post on the Google Android forum:
http://code.google.com/p/android/issues/detail?id=21031
For me personally the biggest issue seemed to be solved as follows (qutoe from comment 25 in the forum post)
"I seem to solve the problem with .apk files not being built automatically until run/debug is used (comments #10, #11 etc.). Go to Windows -> Preferences -> Android -> Build and uncheck "Skip packaging and dexing until export or launch" then restart Eclipse. Works for me."
But there is other useful material there. Different people with different projects seem to have different problems with this setup.
I still don't understand the change in the classpath, but it doesn't seem to matter.
In addition, I found a discussion of installing the ADT with Eclipse Indigo which was helpful here in Stackoverflow:
Eclipse Indigo - Cannot install Android ADT Plugin
I also found that I guess because of various uninstalls/reinstalls, for some reason it stopped excluding my .svn directories from the sources. This Stackoverflow post was helpful with that:
Why is eclipse trying to copy my .svn folders from src to bin, and how can I make it stop?
Finally: a tip for really and truly uninstalling Eclipse - everybody says there is no uninstall, and there isn't, but there is a directory that Eclipse leaves in your home directory (in windows 7 under c:\users\) called .eclipse -
Zap it if you really want to start fresh.
In addition, for less extreme measures, there is Project->Clean inside Eclipse, and you can invoke eclipse with "eclipse -clean" for additional cleansing effects. No idea what, but various helpful people along the way suggested trying that to solve problems.
Ah yes - when I first installed Indigo and tried to build, I got a warning that my Java Compiler Compliance level was not up to snuff, which was simply not true - I have only Java 1.6 installed on my machine.
See this post for somebody who had similar experience:
http://marakana.com/forums/android/general/374.html
For me, what worked was simply going to Project, Properties, Java Compiler, then click on Configure Workspace Settings, and click on Ok in the dialog. Didn't need to actually change anything. Just showed it that everything was ok!
Eventually I indeed did clean out my Eclipse and Android installations (including the aforementioned .eclipse directory, and there's also an .android directory in your home directory which you may want to erase if uninstalling the Android SDK Tools doesn't do that - this actually is uninstallable). Installed everything from scratch and then used the additional information provided above and now it's building my APK.
I hope this saves somebody the hours I spent getting my build back in shape.

Need to configure Android libs on every Eclipse start

After several years with Eclipse and Android development this combination is driving me nuts.
On every start of Eclipse the lib settings I've configured on the page 'Project/Properties/Android' section 'Lib' need to be re-applied.
After a Eclipse restart all existing projects are marked in red. For every project I have to select that project, change to the page described above, remove all Libs, hit Apply, re-enter the same Libs and hit apply again. .classpath and .project look ok. It's the latest Android SDK and the latest Helios Eclipse release. MotoDEV is installed as plugin.
This is a stupid and time-consuming process. Please, has anybody an idea what's wrong with Eclipse (or the Android SDK) or my configuration?
Many thanks in advance.
Which OS are you using and is it 32- or 64-bit? Are you logged in as root/administrator or as a regular user? This sounds suspiciously like the ~/.eclipse folder isn't getting written correctly. We can look at this in MOTODEV Studio and see if it's something unique to us, but it definitely is strange behavior.
Update: one of the MOTODEV Studio team says this is a known bug in ADT when using linked folders. http://code.google.com/p/android/issues/detail?id=14217

Copying an Android Project Folder is Not a FULL Backup?

Several weeks ago I took a snapshot of my Android project by simply copying the entire folder (Windows 7) to a network share.
A few weeks later, I wanted to build that snapshot in a new (and different) workspace. So I:
Created an empty folder for the
workspace,
Switched Eclipse to it,
Then used File > Import... to copy
that snapshot to the workspace.
I was then surprised to find errors in the project - errors that weren't there before I copied it over to the network share.
The first symptom was that only the last file in the project had multiple errors. I "fixed" that by entering into Eclipse (again!) Android's SDK location:
Windows > Preferences > Android > SDK Location: C:\android-sdk-windows
This resulted in numerous files now having errors, with the following hint at the console:
Android requires .class compatibility set to 5.0. Please fix project properties.
I fixed that by hovering over #override and selecting the Change workspace compliance and JRE to 1.5 balloon suggestion. This is strange because I checked Windows > Preferences > Java > Compiler > Compiler compliance level: and it was 1.6 before - Doesn't 1.6 include 1.5?
I was then left with only two errors stemming from #Overrides that shouldn't really be there (for methods implementing interface). So I removed them and now all is fine and the project builds and runs perfectly as before.
All nice and dandy but I was very surprised by the fact that I actually had to change anything in Eclipse, not to mention that I eventually ended up modifying the original source code (deleting #overrides only) to get it build - source code that had no complaints whatsoever weeks ago!
What could possibly explain this? Isn't copying an Android project folder a true full backup?
Being baffled by this discovery, I examined the workspace folder, using my beloved Emacs, and discovered that there is a hidden subdirectory named .metadata. This is probably where the secret lies.
My questions now are:
Does Eclipse store additional
information about the workspace
elsewhere?
What is a good approach to make
Android projects more independent,
as in "fully backup-able"?
Is there any use for the
.metadata/.log file? Can I safely
delete it?
I had those errors too when imported a project. If I'm remembering correctly, helped right-clicking in project name and selecting Android Tools -> Fix project properties...
After that errors disappeared.
“Android requires .class compatibility
set to 5.0. Please fix project
properties.” What’s this? It’s the
error I received after cloning a
repository and trying to import it
into Eclipse. There is reasonably
little information online about this,
couple discussions on mailing lists
but I figured I would write a post on
the solution to this.
After importing the project to your
workspace, you’ve received the error.
So what you need to do next is to
right click on the project -> Android
Tools -> Fix Project Properties. Now
this alone won’t fix the problem, you
need to restart Eclipse after this.
After that try building the project
again and it should work successfully
this time (unless you have bugs in the
code itself, I did).
I've found that Eclipse's metadata is stored, as you found, in the ./metadata folder of your workspace. I do not believe there are any additional folders but I will double check.
The best way to do a back up of the android project if you are using eclipse is to export it by right clicking the project, selecting export and exporting it as an archive, file system, etc. That way you can be sure you've backed it up in a way that Eclipse knows how to handle it.
Rather than delete it, why not make a copy of it first? Edit: I would also take a look at running eclipse.exe -clean in the command terminal. That may be more useful than manually deleting the .metadata folder.

Why does Android Eclipse constantly refresh external folders and take forver?

Just my a new Android phone and I've been tinkering with some basic apps. It's been driving my crazy that the Android plugin for Eclipse refreshes externals folders whenever I save ANYTHING. Normally I wouldn't mind but when it takes 10s to refresh I start to notice.
I already searched and other people have this problem, but there are no solutions.
If it matters, Eclipse 3.5 running on a 64bit jvm on Ubuntu 9.10
If you have references to external sources put them in a zip file:
YourProject->rightClick->Properties->Java Build Path->libraries->..., and then most notably android.jar, but other libs can be the culprit too. Expand it and and select Source attachment, and then (if it doesn't say 'None') press the 'Edit...'-button. If that points to a directory waht you should do is compress that source-directory into a zip file and make the source attachment point to that file.
Apparently eclipse/adt feels the need to refresh sources on the file-system. When they're in a zip-file it seems confident that they have not changed....
You could try disabling "Build automatically" from the Project menu.
First of all Eclipse has a cool feature called a Preferences menu which is located under the window menu located at the top of the screen. Inside there are all sorts settings for pretty much anything you could want to adjust, including the option to turn off Native file system hooks and polling (under General -> Workspace). This is the actual solution to your problem as disabling build automatically doesn't solve the external folders issue, as soon as you build your project it starts right back up with refreshing them. Just keep in mind that if you update your Android SDK at all you will probably need to right click on the root directory of your project and hit refresh after the update finishes.
Secondly, as far as Netbeans is concerned there are at least a half a dozen pages worth of forums posts and various methods for using the Android SDK with it that are also available through Google, I'd give it a look.
I generally do the above step of turning off Automatic build and also try to have not more then 1 open project in my project list.
I myself am fed up of Eclipse from this. Importing a big android project 'ALWAYS' hangs my eclipse and i have to force close it and restart it.
P.S. I really wish google would create an Android plugin for Netbeans =(

Categories

Resources