Huh? Android Preferences page refuses to load after adding SDK 1.6

Question

This one is really weird. I had a perfectly working Eclipse + Android 2.2 SDK working in both Administrator account and LUA (Limited User Account) under Windows XP.

Then I decided to add the Android 1.6 SDK (I could do it from an Administrator account only). It seemed to have gone well, since it still works perfectly -- but only in that Administrator account!

When I try to start Eclipse under a LUA, I receive the following error message box:

Which disappears within 2-3 seconds and replaced with:

I then tried to check the Preferences page, but again, all I receive is error messages:

and:

Any idea why this is happening and how to fix this?

(I would love to be able to continue working from a LUA)

Update: I have uploaded the error log file (referred to in the "Show Error Log" in the message boxes), for your expert examination. Hopefully this can shed some light on the mystery.

Sievert

The lua tag you've added is not for Limited User Account, it's for the programming language Lua. – Pollitt

Oops... sorry. I was referring to en.wikipedia.org/wiki/Least_user_access but I will remove the tag as to not confuse people. – Sievert

Answer 1

Workaround found: Run Eclipse as Administrator (Right-click exe/shortcut, then select "Run as...", then enter Administrator's password).

This is a workaround, not a solution, but it does allow me to continue working while logged in LUA.

Thanks to @David who suggested this solution here: Android ADT Plugin doesn't show up in Eclipse

Update: Solution found:

1. Enable the Security tab in Windows XP Pro (""Use Simple File Sharing.")
2. Add the LUA account to C:\eclipse with Modify permissions.

That's it. No need to run Eclipse via "Run as". Also eliminates the need for a fresh install (which takes more time).

Sievert

Answer 2

The full answer is somewhat complex, concerning Eclipse's configuration area, the workspace area, etc. This is all documented on the Eclipse site, if you're interested.

But there's a simpler, more immediate approach, since you're not trying to run multiple users simultaneously on the same copy, over a network -- in which case you'd need the full answer.

Simply install Eclipse in a directory, say, C:/dev/Eclipse. Make sure both your limited user and your admin have write access to everything. Run Eclipse as the limited user. It should start right up, as there's nothing privileged that is needed by Eclipse.

At this point, you can lock it down as read-only if you desire. By default, all the configuration is stored within the Eclipse installation directory.

I'd suggest starting with a fresh install at this point, to eliminate any inconsistencies that you may have introduced. Though you should be able to reset things by deleting all the subdirectories of the configure/ directory (but not the config.ini). There's an official way to do that, but that's part of the full answer. :=)

I'd also suggest using a different workspace for each user, to avoid any permissions problems.

But my BIG suggestion is -- upgrade to Windows 7, and do NOT run Eclipse as an administrator!

Anyway, once you have it working -- to upgrade in the future, make the Eclipse directory completely writable by the limited user, and then update as the limited user, and then make it read-only again if needed.

Note: This is the cheating way. The REAL answer is to give each user their own configuration directory. This is only viable because you have control over both users and can coordinate any updates.

Schwerin

thanks for your answer. At this point, I have wasted enough time setting up my dev env. It's time to start programming. I am happy for now with the accepted answer. If I have some time in the future, I may try your suggestions. It's good that you posted your well thought answer, though, as it may help someone else facing the same problems. Thanks again. – Sievert

Answer 3

Try running eclipse by downloading the binary and unzipping and directly running the .exe rather than "installing" it. The android tools should work this way if you configure the appropriate paths to them, and if eclipse isn't "installed" but simply run from a the archive folder, it should try to download plugins and such into its own directory (owned by your user), which may solve your problem.

I doubt the Android developers who built the tools run under LUAs, so they probably didn't run into this problem...

Turtledove

quoting you: "I doubt the Android developers who built the tools run under LUAs, so they probably didn't run into this problem." -- if that indeed is the case, it confirms my suspicion that the Android tools are not very well tested under Windows. See #4532343 – Sievert

Also, while I can probably spend the time to try an "unzipped" installation vs. a setup.exe one, I am sure you can understand my frustration when merely adding an SDK breaks an Eclipse setup that was working PERFECTLY (under LUA!) before that. – Sievert

If you can figure out how to install the SDK as your user in question, you'll probably solve the admin problem too. I expect that you set some permissions and/or modified files as that user which are now unavailable to your LUA user. I don't know what they are, but that's a common problem newbie unix users run into as well when they are first encountering su and root. – Turtledove

what admin problem? AFAIAC, there isn't any. The problem is in LUA only but it leads to a more important problem: trust. If I can't trust the tools to behave "as advertised", how can I do schedule projections? It's impossible for me to estimate the length of a project, when I assume an SDK addition would take me 1 hour max, then I spend an entire day looking for a solution, and the problem is not solved yet. I know I can workaround it by abandoning LUA and work in admin only, but that leaves me with a horrible feeling (and a question whether my smartphone platform choice was correct). – Sievert

although your answer didn't solve my problem, I am giving you +1 for the only attempt to help (so far). BTW, I managed to upload the error log file (see link in update to original message). I am not very experienced in Java, so the log still looks cryptic to me, but perhaps someone else with more experience could decipher it. Thanks. – Sievert