Posted on

CentOS 7 aapt ELF and Missing Lib

While building an Android Studio app the build failed with aapt errors.   The aapt part of the build started off with a missing error.    Turns out I had already installed the zlib library with yum install so already existed in /usr/lib64/.    The problem was with the library path.   That is easily fixed.

Put these commands in your ~/.bashprofile as well:


However the ELFs were not happy.    For those that don’t know what an ELF error means, it has something to do with byte offsets and library file formats.  Turns out it is a cryptic way of telling you the program is trying to load a 64-bit version of the library it needs instead of the 32-bit version.

Again an easy fix;

# sudo yum install zlib.i686

# LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/;/usr/lib64/;

The .i686 versions of the yum install kits are the 32-bit versions of the libraries.  They are placed in the /usr/lib directory.  Setting LD_LIBRARY_PATH helps the 32-bit dynamically linked executable find the proper link library.

Now on to building this Android app on my CentOS dev box.

Posted on

Unable to run mksdcard SDK tool CentOS

Android Studio Banner

Installing the Android Studio on my CentOS 7 development system went fairly well once I loaded the latest Java JDK from the standard yum repository.   During the install wizard I did run into an issue with a generic “Unable to run mksdcard” error message.    This is the studios watered-down message from the actual command execution.   You can get more details by going to ~/Android/Sdk/tools and running mksdcard from the command line.

# cd ~/Android/Sdk/tools

# ./mksdcard

Here is where I found the compiled executable was missing some 32-bit libraries that are required to run the exe.

bash: ./mksdcard: /lib/ bad ELF interpreter: No such file or directory

A bit of digging and I found I needed glibc, which after another attempt to execute mksdcard told me I also needed  By using yum whatprovides I learned both packages I needed to install.   These additional installs helped get Android Studio up-and-running on CentOS 7.

# sudo yum install glibc.i686

# ./mksdcard
./mksdcard: error while loading shared libraries: cannot open shared object file: No such file or directory

# whatprovides

libstdc++-4.8.2-16.el7.i686 : GNU Standard C++ Library

libstdc++-4.8.2-16.el7.i686 : GNU Standard C++ Library

# sudo yum install libstdc++-4.8.2-16.2.el7_0.i68


With those couple of new libraries installed the Android Studio app is now running on my CentOS 7 development box with the MATE desktop UI.


Posted on

Rhomobile : rhoconfig.txt cheat sheet

We have recently been working with Rhomobile to test and deploy some business class mobile apps.  So far the testing has gone well, however the documentation at the Rhomobile site is lacking in some areas and has fallen behind the mainline development.  The Rhomobile forums are also a good source of information but it is obvious Motorola is having some trouble keeping up with the developers that seem to be discovering this hidden gem (pun intended… Rho is ruby-centric).

As we learn more about developing with Rho, we have found some unique things about the environment.   Here we post some notes and hints.    We will add comments or extend the post with more hints as we come across them.


splash_screen settings

The following settings are the possible values in the 3.3.3 release:

  • splash_screen=’zoom’ (default)
  • splash_screen=’none’,  android = no effect
  • splash_screen=’hzoom’, android = no effect
  • splash_screen=’vzoom’, android = no effect
  • splash_screen=’hcenter’, android = no effect
  • splash_screen=’vcenter’, android = no effect

Derived from the source in <installdir>
hodes-3.3.3\platforms\shared\common\SplashScreen.h and SplashScreen.cpp

There are developer notes in some “random forums” that this was re-factored in 3.3.3 to always zoom/stretch to fill the screen at all times (zoom).



Posted on

Mobile Cross Platform Development : Corona

Anscamobile CoronaWe recently wrote an article on our experience using Apache Cordova to build cross-platform mobile devices.   It works for quick prototypes or simple mobile apps but the are compromises.   Here we touch on our experiences using Corona by Ansca Mobile.

Testing The Apps

One of the things we dislike about Corona is the fact that testing on an ACTUAL DEVICE is a cumbersome process.  The short version, build the app, find your OS level tools, manually push the app into the phone.  Doesn’t sound hard until you start playing with command-line tools to move stuff around.  Yeah, we are tech geeks, but who wants to see this sort of thing constantly during the build/test cycle?

Corona Android App Install

Another fun “feature” of this method is what happens when you are UPDATING an app for testing.  Since you are using the command line the process of updating needs to be done in a 2-step process, UNINSTALL first, the install.  Forget to uninstall and you get an error.   What is a simple 1-step GUI operation in Eclipse with Cordova becomes a 2-step command-line operation in Corona, and that becomes 3+ steps if your command line interface is not already open.

Cordova Wins This Battle…

The Eclipse interface used with Apache Cordova is FAR EASIER.  Select “run”.  If a single mobile device is attached it loads and runs.  If more than one is attached it asks “one which device”.  If none are attached it runs in the simulator.

Corona wants to ALWAYS run in the simulator. The simulator is good, but not great.   We often see graphic anomalies.  You also have no way to test the camera, or other real-world things like degree of tilt, etc.  Testing on a real-world mobile device should be 10x easier with Corona.

Documentation Out of Date

There are a number of areas where the documentation for Corona is out-of-date.   This is a huge problem for people not familiar with the Corona builds.   Sadly you often have to search the forums to get accurate functionality from other Corona users.    For example, the Android GPS permissions are documented in the Corona API and Build settings with obsolete settings:

settings =
android =
versionCode = “3”

androidPermissions =

orientation =
default = “landscapeRight”

The proper settings are noted in the forum:

In Corona, you can add these <uses-feature> tags via the “build.settings” file as follows…

settings =

android =
usesPermissions =
usesFeatures =
{name=”android.hardware.location”, required=false},
{name=””, required=false},
{name=”android.hardware.location.gps”, required=false},

With a note by a Corona guru …

We added “usesPermissions” and “usesFeatures” as of build 704. We haven’t documented them yet. So, I apologize for the confusion.

Sadly this note is over 2 months old and the documentation is still wrong.

Android Features Missing

One of the problems with Corona, as noted in our prior article about Cordova, is that there is no support for some device specific features.  Two of these , camera and orientation change, are key to many mobile apps and quickly eliminates Corona from consideration.

From the Corona website Android build docs:

The following features available for iPhone devices are not yet implemented, or fully implemented, for Android device builds:

Activity indicator
Orientation changes
OpenAL audio: limited support

More shortcomings, in our first attempt we find out we can’t use the map API, which sucks as we are building a map application.

MapView is currently iOS-only, and therefore will not run in the Corona Simulator. Build for iOS devices or for the XCode Simulator to use this feature. For an example of many of these APIs, see the new “MapView” sample project distributed with the SDK.

From the Corona Map API page

Notes about the Android issues, which affect Kindle Fire and Nook, are prevalent:

On Android, the default orientation setting has no effect. The orientation is initialized to the actual orientation of the device (unless only one orientation is specified). Also, the only supported orientations are landscapeRight and portrait. On a device, you can flip to either landscapeRight or landscapeLeft, but the OS only reports one flavor of landscape, and Corona’s orientation event chooses landscapeRight.

From the Corona Configure Projects page.

Vendor Lock-In

Perhaps one of the most troublesome issues with Corona is the vendor lock-in.   When using this system you only retain and have control of the Lua code.   The problem is that the pre-processors and compilers run on THEIR servers. That means Corona has the actual source code for the Java and Objective-C version of your Lua code.

If Anscamobile goes out of business, you are out of luck.   If you let your subscription expire you are out of luck.  If they raise subscription prices by 5,000% you are in trouble.   If their servers crash, your internet connection drops, or any other number of issues come up you cannot update your apps.

If you go this route you are absolutely tied into & dependent on Corona for your mobile apps survival.   Is that part of your business plan?  Is Corona listed as a business partner?  If not, they are a partner now whether you like it or not.


It is very clear early on in the evaluation process that Anscamobile’s Corona environment heavily favors and is geared for the Apple developer.   There are numerous shortcomings and missing features for Android devices.   That is odd since they tout the Android, Kindle, and Nook devices which are all distinctly non-IOS platforms.

It also seems as though there are a lot more “cant’ do that on the other platform” shortcomings with Corona than Cordova.   Yes, Cordova has issues as well, but there seems to be a much more concerted effort to get every feature in Cordova to work on all platforms.

Thus, Corona looks like a solid IOS development platform that *may* get some apps over to Android.  However, if you are going to build in what is almost an IOS only environment, why not just build with Objective-C?    Essentially Corona feels like a Lua-language alternative to Objective-C for people that find Objetive-C too hard to code in.    The cross-platform support still has a ways to go.

Posted on

App Inventor First Impressions : Coding An App

Google App InventorWe finally got our first App Inventor mobile application built and are underway on our second app. Here are our first impressions of building an actual app.

First App – The Pat A Cat Tutorial

The initial tutorial went very easily, after the fight to get the development environment set up. The first application took less than 5 minutes to create and get working, even in a standalone packaged app sent to my phone. I glossed over the “pet a cat” tutorial then created it without referring to the docs. It was very intuitive.

Second App – Barcode Scanner

The second attempt was a basic prototype of a far more complex application that was created with Eclipse and the Android SDK combined with the open source Zxing project. The idea is to have a simple bar-code scanner that when it scans a valid bar code calls a URL for one of our client sites and returns back the price they will pay for a book, dvd, cd, or video game.

With the initial Eclipse based project we had a standalone and fully self-contained app on-line within a hour. It worked well for a prototype and provides all the elements we need for a full blown app. It has to be coded in Java and requires a coding background.

With App Inventor we have a few hurdles as outlined below.

Hurdle 1 : Separate Install of Zxing Required

The built-in scanner class requires a third party application, the freely available Zxing App, to be pre-installed on the phone. That means if you were to put this into production all of your users would be required to go fetch and download another app before they could use this app.

Hurdle 2: Checking/Launching Third Party Prerequisites

Maybe I’m missing it, but I don’t see a simple way with the drag & drop interface to check if a third party app such as Zxing is already installed when running my new test app. That means we will only be able to wait until someone tries to scan, catch the error (we have error catching abilities, right?  We’ll need to look into that), and then tell them to exit the app and go install something else then come back.

There also does not seem to be any way to automatically launch a third party app other than the select few that Google App Inventor supplies. So that means not launching the marketplace and sending them a “search for zxing” command. Luckily we can launch a web browser with a URL, but that is not exactly the same.

Hurdle 3: Bundling Other Apps/Libs

The best solution would be to bundle the other app along with our app so that installing our test app automatically installs Zxing. Even better would be the ability to make it a self-contained component within our test app.

Test 2 Summary

All-in-all we could knock together a simple prototype of our new scanner app, but it would be a rudimentary version of the final app. Not being able to bundle Zxing easily and, even better, including the libs directly in our project, makes it hard to sell this as a consumer friendly application.

Of course this is a new IDE we are playing with here. Maybe all of this is possible for the expert App Inventor developer, but for a noob the methodologies are not readily apparent.

Initial Thoughts

After a full day of playing with App Inventory, here are my initial thoughts. The environment is perfect for simple to somewhat moderate level applications. It is good for things like a basic toddler app or a simple limited use consumer app. It may even be able to do some more complex tasks.

It is not going to build something like Angry Birds. Not even close (I know, that is not really what this IDE is for, at least not yet). It also is going to be difficult to create anything that is not based on down-the-middle business forms or simple media interfaces. Showing pics, playing sounds, firing off the camera or phone apps… no problem. But trying to complex interactions with any of those devices becomes more & more of a challenge to the point that learning some Java and using a full blown IDE starts to make sense.

So for a casual mobile app hacker that wants to create some simple apps for their kids, themselves, or their business it is great. It is also a good prototyping tool. Heck, you can even create some marketable apps here with some effort. At some point you will outgrow the environment and will want to start learning Java. This is a great way to get a layperson interested in the craft of computer programming though, and even teach them the basic concepts of logic and device interaction along the way. A perfect 101/201 level class in application development.

The only problem for a large number of casual app hackers is that you may need a comp sci Phd just to get the environment setup. And therein lies the rub. Google App Inventor is obviously targeted squarely at non-technophiles, the layperson that has an idea and a little bit of computer coding knowledge, NOT a hard-core tech geek. Yet, as you may have noticed in my prior posts, just getting setup can be a trail in patience and computer expertise. Yes, I have a “talent” for making technology break… any of the guys on my team will tell you that, but I assure you I’m not the only person who  will run into problems.

A promising start, and a great fit for the right people. We’ll probably use Google App Inventor for some of our own simplistic apps and definitely for more than one prototype. However, for prime time level A applications it is not there yet.

Posted on

App Inventor First Impressions : Signing Up

Google App InventorGoogle App Inventor is a service and development platform provided by Google to make it easier to create and deploy Android mobile applications. I am reviewing the viability of this platform now that the technology has matured a bit and is gaining more acceptance in the community. It appears this project may have some longevity, which is always a concern with any Google endeavor.

One of the risk factors of a service like this is that the provider can pull the plug at any time. As many companies have learned along the way, if you rely on a Google Labs project as a core part of any project you may well find yourself re-inventing and re-creating on relatively short notice. Google has a history of dropping anything they consider a failed project with little advance warning.

Terms of Service

Nobody ever reads this things. You should. Especially when it comes to basing your next big money making software product on a platform somebody else OWNS. That’s right, Google OWNS the platform. That means they can make changes that directly impact your ability to produce, update, and continue to sell your project. If you’ve got the next Angry Birds on this platform you really don’t want rely SOLELY on an external organization, even one that will seemingly be around “forever”.

Here are some notable items in the TOS from Google App Inventor:

4.2. Google reserves the right (but shall have no obligation) to pre-screen, review, flag, filter, modify, refuse or remove any or all Applications from the Service. Google reserves the right to directly take down any Application that violates these Terms, any applicable Program Policies, or applicable law or regulation.

In other words, Google can pull the plug on your project at any time for any reason and even stop your product from being listed in the first place.

4.4. You agree that Google has no responsibility or liability for the deletion or failure to store your Application and other communications maintained or transmitted through use of the Service. You further acknowledge that you are solely responsible for securing and backing up your Application.

If they do pull your project, oh well. You are on your own. You cannot sue them if your $5k/month revenue stream suddenly goes away because they pulled your app.

5.3. Except as provided in Section 7, Google acknowledges and agrees that it obtains no right, title or interest from you (or your licensors) under these Terms in or to any Application that you create, submit, post, transmit or display on, or through, the Service, including any intellectual property rights which subsist in that Application (whether those rights happen to be registered or not, and wherever in the world those rights may exist). Unless you have agreed otherwise in writing with Google, you agree that you are responsible for protecting and enforcing those rights and that Google has no obligation to do so on your behalf.

Unlike some other online services, Google does not get any ownership of the project you post on this service. What you create you own.

7.2. You agree that Google, in its sole discretion, may use the trade names, trademarks, service marks, logos, domain names and other distinctive brand features of your Application in presentations, marketing materials, customer lists, financial reports and Web site listings (including links to your website) for the purpose of advertising or publicizing your use of the Service. 7.3. If you create an Application to share with other users of the Service, you may determine with whom you share the Application and grant to such users a non-exclusive, worldwide, and perpetual license to perform, display, and use the Application.

While you retain ownership of your app, if you have the next runaway hit Google can leverage your brand awareness to their benefit. In other words if you create the next Angry Birds app, Google can promote the heck out if it in their marketing pitch for their service… “Joe’s Super Cool App was created with Google App Inventor” and plaster that message all over the place. I see no real downside in this, but it is something to be aware of in case you later think “hey, they should be paying me to use my notoriety” once you get rich & famous.

What Is App Inventor?

App Inventor is a project manager and web based IDE (integrated development environment) for Android mobile apps. Like most IDEs these days the App Inventor starts of by being a graphical design environment. You “draw” how you want the app to look first, then connect functionality later.

“Real” programmers don’t necessarily like this as it can allow for some very sloppy coding. It also allows programming “noobs” to get in on app development without understanding the design principles of creating sustainable applications. However it is a great way to start an application for a mockup or to create simple applications that don’t require complex process flows.

In Progress…

I am now off to create my first App Inventor app. Stay tuned for follow up articles on the Google App Inventor IDE.

Posted on

Setting Up For Android Development

I woke up a little before four in the morning and could not go back to sleep, so I decided to start working on a framework for hone quiz applications we talked about yesterday, tentatively known as A Quiz and Teaching Environment: a.k.a. “AquaTeen”.

My development came to a grinding halt because I need the sun-java6-jdk package, which I can’t get until I get to the office. Even if I could connect to the Internet right now, my connection here is slow, and that package is anything but small.  It would not finish downloading between now and then anyways.

In the mean time, here’s how I got up and running doing Android development.

1. Get the latest Java SDK.

2. Go to the Android development site and download their dev kit for your appropriate operating system.  It is a zip file around fifteen megabytes in size.

3. Unzip that file to wherever you want to store the Android tools.  On Windows I imagine this is an installer that you will be running.

3.a. If you are on Linux then I suggest making these tools available via $PATH.  For example, I installed everything in ‘/home/eric/Software/Android’.  So then I tacked that directory on to the end of my $PATH, by putting this in my Bash configuration


which lets me run the Android tools from any directory.

4. That dev kit will have a tool called ‘android’.  Run this, and you will see a GUI package manager for the Android platform.

4.a. I had to go into Settings and tell it to fetch packages over ‘http’ instead of ‘https’.

5. Refresh the package list and check off the things you want.  I installed the latest 2.1 documentation and SDK.  Then let the manager install those tools.

Then you will have all the tools you need.  Now you have to setup your development environment.  Out of the box, Android provides support for two IDEs: Eclipse and Emacs.

* Eclipse :: There is an ADT plugin that comes with the Android platform for creating Android projects and integrating with tools like the emulator.  I did not go down this route (imagine that) but it sounded simple enough to set up.  I believe you will need Eclipse 3.5 for this, which you should have anyways if you use Eclipse.

* Emacs :: In the place where you installed Android you will find a file ‘/tools/libs/android.el’.  Put this wherever you store
your Emacs libraries and (require 'android) in your Emacs configuration.  I also recommend finding ‘android-mode.el’ by R.W. van ‘t Veer and loading that as well.  It provides an Android minor-mode that let’s you spawn off things like the
emulator and debugger out of Emacs.

For development you will need an Android Virtual Device, or AVD.  You can create these using the same package manager mentioned above.  At a minimum you will need one of them, although you can create as many as you feel like.  Keep track of the name of the main one you want to use.  In Eclipse and Emacs you can designate a default AVD to use for testing.  In Emacs this is done by setting the value of android-mode-avd.  I suggest just doing this by running Customize, i.e.

M-x customize-group <RET> android

But if you wanted to put it in your config file, or a special Android config, you can write something like:

(setq android-mode-avd "MasterShake")

Once you’re environment is setup you can create a project.  I already made one for the AquaTeen project and put it into version control, so that one can simply be cloned.  But here’s how you create new projects from scratch.

1. Find out what platform versions you can target by running:

$ android list targets

You will probably only see one result.  You will need the target ID number.

2. Run the ‘android’ tool to create the project.  Here is what I did, then I’ll explain the parameters:

$ android create project     \
--target 1                 \
--path ~/Projects/AquaTeen \
--activity Quiz            \
--package com.cybersprocket.aquateen

The target is the ID of the platform you got from the first step. The path is where you want to create the project.  In that directory Android will create all the stub files you need to get up and running.  The package is the namespace you want to use for code on this project.  These things are straight-forward.

The activity is the name of the activity class you want to use, and requires the most explanation.

Android applications do not have a single-entry point.  That is to say, there is no ‘main()’ method anywhere.  One Android application can re-use parts of another Android application (if that other app allows it).  This makes it possible to re-use things like UI elements across different apps.  This is accomplished via “activities”.  Each activity in an application is responsible for providing some aspect of user interaction.  If you application lets the user do multiple things, those are all represented by separate activities, and each activity can be the starting point for running the application.

When creating a new project you provide the name of an activity, because you at least need one.

If all is right in the world, with all of this done you can go into your project directory and run:

$ ant debug

Or in Emacs ‘C-c C-c c’ to compile the project.  But that’s where I ran into the problem of not having the Java 6 JDK, so I can’t help you beyond that point.