Setting up Android in Eclipse, Unable to resolve target ‘android-18’

When setting up Eclipse for Android development, after you have installed the Develeper Tools and NDK Plugins and linked to the ADT-bundle and then imported your project (see othere posts related by searching for ‘android’) I got the following error:

[2014-03-24 14:14:53 - android_sdk] Unable to resolve target 'android-18'

I went and checked to make sure that the Platform.MinPlatformToolsRev property in the ~/path/to/adt-bundle-linux-x86_64-20131030/sdk/tools/source.properties matched that of my project.properties file.

They were both 18.  Eh?  Why the error?

So, in Eclipse, I went to the Window > Android SDK Manager and looked at the version of the Android SDK Platform that was installed.  It was:

Android 4.4.2 (API 19) and the checkbox next to SDK Platform under that sub-heading was checked.

So, I went back to my project.properties and updated the target property to:

target=android-19

which eliminated that error.

Invalid Project Description, project path overlaps the location of another project with the same name When Importing Existing Android Project in Eclipse

I’ve got a new install of Eclipse and am setting up to do some Android development.

After getting the Develeper Tools and NDK Plugins installed and linking to the ADT-bundle that I downloaded, I was getting an error when attempting to import the existing project by going to File > Import > Android > Existing Android Code Into Workspace.

The error was:

Invalid project description /some/path/to/project/dir_name overlaps the location of another project: dir_name

After a few searches and a couple of tries, using the File > Import > General > Existing Projects into Workspace seemed to work just fine.

Creating a Beep from a Command Line or Shell Script

If you have a long-running command on shell-script that you want to generate a beep upon completion on your PC running Linux do the following:

Make sure that the pcspkr module is loaded:

# modprobe pcspkr

Then create a wrapper shell script that looks something like this:

#!/bin/bash

# Some long running command here . . .

echo -e '\a' > /dev/console

Eclipse Crashing with SIGSEGV, Problematic Frame libgdk and/or libsoup Problem Solved

I’m setting up a new workstation under Fedora Core 20 and getting my dev environment set up.

I had copied over my /opt dir from my old machine which included an older version of Eclipse (3.8.2) that I had been using.  That version wasn’t behaving very well and I decided to go with the latest and greatest stable version (Kepler, 4.3.1).

Unfortunately, Kepler was dumping core with the following error:

 A fatal error has been detected by the Java Runtime Environment:

  SIGSEGV (0xb) at pc=0x00000030f703d09a, pid=2450, tid=139984564643584

 JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)
 Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops)
 Problematic frame:
 C  [libgdk-x11-2.0.so.0+0x3d09a]  g_param_spec_object+0x3d09a

 Core dump written. Default location: /home/rchapin/core or core.2450

I realized that I had installed Acrobat Reader, and since I’m on a 64 bit architecture that included all of the i686 rpms and compatibility libs.  I thought that that for some reason there might be some confusion between which version of libgdk that was being used.  That wasn’t it.  I tried a different JDK (Oracle vs OpenJDK), nope, that wasn’t it either.

Eventually, I tried deleting (actually moving aside) the .eclipse/ dir in my home dir and deleting all of the .classpath, .settings, and .project files and dirs in my workspace and then re-installing my Eclipse plugins for Kepler.

Worked like a charm.

What I think was happening was that some of the plugins for different versions of Eclipse were being pulled in at runtime and causing the Kepler binary to crash.

Excellent Example and Explanation on How to Inject Properties from an External Properties File from Outside of a WAR in a Spring Application

I am doing some refactoring on a Spring MVC application, pulling out configuration data and login crentials from the spring.xml file.

What I want to do is to consolodate sensitive data into external .properties files that can be read, at runtime by the app and not require recompiling the war to make changes.

Thanks to Ben Northrop and Summa Technologies for such a clear, concise and well written article.

The long and the short of it (copied from the aforementioned article) is to add the following to your spring.xml

<bean id=”propertyPlaceholderConfigurer”  
class=”org.springframework.beans.factory.config.PropertyPlaceholderConfigurer”> 
  <property name=”locations”> 
    <list> 
      <value>classpath:database.properties</value> 
    </list> 
  </property> 
</bean> 


<bean id=”dataSource” class=”com.mchange.v2.c3p0.ComboPooledDataSource”> 
  <property name=”user” value=”${db.user}”/> 
  <property name=”password” value=”${db.password}”/> 
  … 
</bean>

Executing Dynamically Generated SQL Queries in a Shell Script and Saving the Output to a Variable

If you would like to, in a shell script, dynamically generate SQL queries for MySQL and save the output of those queries to a variable that you can then use in the script, here is an example:

#!/bin/bash

for i in `cat tables_list.txt`
do

   # Build the query
   QUERY="SELECT count(*) FROM ${i}"

   # Run the query from the command-line and save the
   # output into the $ROW_COUNT variable
   ROW_COUNT=$(echo $QUERY | mysql -u${USER_NAME} -p${PASSWORD} -h ${HOST} -P ${PORT} --skip-column-names ${DBASE})

   # Do something with the var...
   echo -n -e "$ROW_COUNT\t" >> $OUT_FILE
   echo "$i" >> $OUT_FILE

done;

Executing Dynamically Generated SQL Queries from a Shell Script

Following is how to generate dynamic SQL in a shell script and then execute those queries.

Let’s say, for instance, that you have a list of tables that you want to flush regularly during development and don’t want to type in the SQL queries each time.  Moreover, you just want to maintain a list of the table names and add and remove from it when necessary and have your script dynamically generate and execute the delete statements.

For the purposes of this tutorial we are running these commands as root to avoid the additional complication of authentication.

The first thing you need is your text file with the list of your tables:

table_list.txt:

table_a
table_b
table_c

delete_data.sh:

table_list.txt:

table_a
table_b
table_c

delete_data.sh:

#!/bin/bash

for i in `cat tables_list.txt`
do

   mysql -u root dbase_name << END_SQL
   delete from ${i};
END_SQL
#
# It is imperitive that the END_SQL redirect identifier
# be on its own line without any leading or trailing spaces
#

done

The script will run, will make a connection to MySQL and then execute the command with the dynamically generated target table.

This will work with other databases other than MySQL as well.

Setting Up Android SDK and Plugin in an Existing Install of Eclipse

To set up an existing install of Eclipse to do some Android development do the following:

  • Go to http://developer.android.com/sdk/index.html and look for and download the ADT bundle for your OS (in my case I was using Fedora Core 18 at the time)
  • Unpack it as the user that is going to be running Eclipse and/or after you unpack it make sure that your user has read/write/execute permissons for the files in this directory (obviously, you don’t need execute permssion for non executables).  To make things easy, I just created an ~/sdks directory and unpacked it in there.
  • Fire up eclipse and go to Help/New Software.
  • Add the following repository: https://dl-ssl.google.com/android/eclipse/
  • Check off both the Developer Tools and NDK Plugins.
  • After those plugins install go to Window/Preferences/Android, and click the ‘Browse’ button next to ‘SDK Location:’, selecting the /path-to/adt-bundle-linux-x86_64-20130917/sdk.  When setting this up you might get a dialogue box that indicates that the version of the Android SDK Tools and/or Android SDK Platform Tools is not compatible with the version of the adt-bundle you are attempting to use.  In my case, I was prompted to update it via the Android SDK Manager and was able to download an updated version.

If you have an existing project that you are working with you might have to update the project.properties to update the sdk level number.

You might see an error like:

Unable to resolve target ‘android-17’ until the SDK is loaded

If so, update the ‘target=android-17’ property in the project.properties file to match the value of ‘Platform.MinPlatformToolsRev’ in the /path-to/adt-bundle-linux-x86_64-20130917/sdk/tools/source.properties file.

In my case, I updated the project.properties to:

# Project target.
target=android-18

Getting the value ’18’ from the source.properties:

Platform.MinPlatformToolsRev=18

Do Not Use Symlinks in Jetty’s webapps Directory

I set up a development instance of Jetty on my local machine and have been happily coding, compiling and deploying via a shell script.  The script copies the war from my user’s target directory to the jetty users’s home dir changes the permissions and then moves it to the /webapp dir creating a symlink to the name of the .war that is referenced in a number of config files.

This was working just fine until I did a merge with another developers code and a significant portion of it changed that Jetty had problems determining whether or not is should dump it’s local cache of .class files and configs and got into a very funky state.  Unfortunately, not one in which it was obviously funky, but where, all of the sudden I could not look up defined DataSources in JNDI.

Ultimately, after looking through many other different things, I decided to delete the symlink and, rename the .war in the /webapps dir.

Bingo, worked right away.