Posted on

Samsung Galaxy S5 Random Factory Reset

Yup, here again. Setting up my Samsung Galaxy S5 after a random factory reset. Unfortunately, in today’s connected world the phone has become the linchpin of my techno-geek world. My two-step authentication system ensures it takes an extra 20 minutes to log into any service I care about when my phone is MIA. Thousands of messages, contacts, and other data needs to be re-downloaded into the phone so I know who (843) 555-1212 is on SMS or when a telemarketing agency is calling. It takes HOURS to reload all the moving parts.

Galaxy S5 Reloading. Again.
Galaxy S5 Reloading. Again.

What a huge pain!

Turns out I’m not alone.

Random factory resets of Samsung Galaxy S5 phones are a known phenomenon that apparently Verizon and Samsung are content to ignore. Too hard to reproduce so it must be user error. Or a bad app. Couldn’t possibly be an issue with Samsung’s hacked version of the Android OS or bad firmware, right?

Android Lollipop Barfing

The most likely and most common problem with the random factory reset appears to be related to corrupted cache files in Android OS after a system upgrade. Interestingly, all 3 times that my phone decided to just reset for no apparent reason it was within 2 weeks of an Android Lollipop update pushed out by Samsung.

Very coincidental, isn’t it?

Turns out that the fix is… A HARD FACTORY RESET.

Wonderful. The only solace with that fix is that you may get to spend the two hours reloading your phone during a time in your life when it is the least inconvenient.

Really not much different than a random reset, but at least you know its coming.

To start the process power off your phone then hold down the power, volume up, and home button at the same time. When you see the loading screen with blue text at the top you can release the buttons. Follow the on-screen menus to do a full factory reset and data wipe.

Yes, this is like getting the phone for the first time. Yes it sucks. Yes you will need to reload all your stuff (you do use Google and Samsung and a third party backup service right? You’ll need all 3 if you don’t want to re-invent the wheel every time this happens). No, your home screen, keyboard, and other configuration settings will not come back. Now you know why so many Samsung S5 users have the default screen. Why customize when you’ll be back to that default in 3 months whether you like it or not.

Bad Battery

Very rare.  However if your battery is defective it will overheat and warp.  Take the battery out.  Put it on a flat surface.  If it does not lay flat on the table you need to replace the battery.   Good luck getting it repaired under warranty.   Luckily batteries are inexpensive.

Bad Apps

Some sites, typically Samsung or Verizon-driven forums and support personnel, claim apps can cause the factory reset.  Sure.  Very unlikely as that is a HUGE security nightmare in Android OS, but I guess anything is possible.   The suggested fix is randomly delete apps that were loaded on your phone until the problem goes away.   Uhhh… exactly how often does a random factory reset happen?   That is like closing your eyes in a dark room, spinning around in circles, and trying to pin-the-tail-on-the-donkey without ever turning on the lights to know if you were successful.

Personally I think this culprit is nothing more than fairy tales and pixie dust to keep you busy and away from the support people.

Samsung OS Updates

Ultimately I think Samsung and Verizon need to stop screwing with the base Android OS builds to cram in a ton of crappy apps nobody wants.   Those apps are nothing but modern day spam that most people don’t want.  They consume excess memory and screen real estate with the only purpose being to line the pocket books of Samsung for hocking other people’s wares.   Wake up.   Nobody wants your crap and if they could delete all the force-fed shit on the phone for more memory and storage space and less app problems they would do it in a heartbeat.

Stop “tweaking” the OS and make a stable version that does not randomly reset every few months.

IOS – The Gold Standard

Sadly, if they ever DO make that version there will be more-and-more people like myself that will refuse to install the update for the ever-present fear of incurring the curse of the random reset.   Instead many people will be in the same situation I am.  Just waiting for my 2-year contract to expire so I can finally stop fooling myself into thinking that Android will every be a gold standard.   iPhone IS the gold standard which is readily apparent by every single device-and-service you could ever want to use granting Apple front-of-line status and relegating Android users to play the role of red-headed stepchild.    Starbucks.   BMW. Smart Lock.  Smart Home.  And big luxury brand has full-feature apps on IOS and half-baked crap and Android.


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

Find Your Android Phone With Play Store

Banner Google Play Store

Lost your Android phone somewhere in your house, car, friends house or other undisclosed location and cannot find it? Not that I’ve EVER done such a thing, but I did stumble upon a feature in the Google Play Store that I never knew existed…

Geolocate and RING PHONE.

Android Find Phone
Android Find Phone

Where is this feature hidden?

Right out in the open on Google Play.

Surf to

If you are not already logged into your account, log in to the same account you use to setup and sync your Play Store apps on your Android device.

When signed in you will see the settings icon, a gear in the top right corner of the page.   Click on that and choose “Android Device Manager”.

Google Play Android Device Manager
Google Play Android Device Manager

Google will ping your device, get the GPS location, show it on the map and give you an option to ring the phone at full volume for 5 minutes.

If the battery is dead you are on your own.

At least you don’t have to borrow a friends phone to ring your cell… though you may need to borrow their computer to surf to the Google Play Store!

Posted on

HTC Incredible 4G LTE Drivers

No matter what I tried I could not get my new HTC Incredible 4G LTE to show up on my Windows 7 (64-bit) system.   I found a TON of posts and sites, mostly spam sites, giving me advice or trying to get me to install something I didn’t need.    At the end of the day the solution that worked is ridiculously simple.

How I Got Win 7 To See My Incredible

Two easy steps:

1) Make sure I was not running in debug mode (not a default, but I develop mobile apps so I had this on).

2) Select “Media Sync” as the mount mode.

Turning On Media Sync

If your phone is acting normally it will sense the connection to a PC when you connect the USB cable.  If not, make sure you are using a qualified micro-USB cable that provides both data and power connections.  The cable that came with your phone definitely has this as will 99% of after-market cables.    I had “mucked with” my phone so much that that connection did not always come up.

You can change the connection type manually by going to your phone settings, and going to “Connect to PC” and changing default type to “Media sync”.  Disconnect and re-connect the phone.     When I did this my phone magically was recognized by Windows 7 and the phone driver was automatically installed.

My HTC Incredible 4G LTE is shown as an “Android Phone” device name “ADR6410LVW”.

HTC Incredible 4G LTE Driver Details
My HTC Incredible 4G LTE driver details.

Failed Attempts

Oddly enough with ANY other mode the phone was seen as connected but windows update would always say “could not locate driver” and leave it as an unrecognized device.   I also had downloaded the HTC Sync Manager and installed it.  That created a folder in my Program Files (x86) directory with Windows 7 64-bit drivers as a folder but NONE of those drivers, even after installing them manually worked properly.

Some of the things I tried:

Verizon Backup Assistant

Huge bloated software that tries to be a PC backup for your media, but is a poor excuse for a backup app.  If you want backup go use Crash Plan.   In addition the Verizon Backup Assistant, or BA Plus as they call it, requires Apple QuickTime.  Talk about bloat.  Then when it runs it is very unstable and hangs frequently.   Worst of all it never “saw” the HTC Incredible so the threads that said this would install the proper drivers did not help one bit.

HTC Sync Manager

Much cleaner & lighter than the Verizon app, and a native Windows 64-bit application.   It looked like a nice UI and did create a drivers folder with HTC Incredible 4g drivers for Windows 7.  In fact I may very well need those when I do my Android apps and need to connect with the ADB (Android Device Bridge) but they DID NOT help my PC “see” the Incredible and I could not mount it as a hard drive in either “Disk Drive” or “HTC Sync” mode.


At the end of the day simply changing the connection type to “Media Sync” got all the pieces I needed.   Hopefully that will work for you as well.  If not, here is the driver kit that was installed “automagically” for me in my Windows System 32 folders:

DRIVERS\UMDF\WpdMtpDr.dll  6.1.7600.16385 (win7_rtm.090713-1255)
DRIVERS\ winusb.sys 6.1.7601.17514 (win7sp1_rtm.101119-1850)
DRIVERS\WUDFRd.sys 6.2.9200.16384 (win8_rtm.120725-1247)
WpdMtp.dll 6.1.7600.16385 (win7_rtm.090713-1255)
WpdMtpUS.dll 6.1.7600.16385 (win7_rtm.090713-1255)

Hope this saves you a few steps.

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

Mobile Cross Platform Development : Cordova

Apache CordovaApache Cordova (aka Phonegap).

A little clarification on the name.  The NEW name will be Apache Cordova.   After Adobe bought the development firm that was working on Phonegap the Phonegap project itself was given to Apache Software Foundation to maintain its open source roots and continue development.  As of this writing the transition is still underway with MOST, but not all, elements haven taken on the Apache Cordova persona.

Our First App On Cordova

Our first app that we wrote using Cordova was the Abundascan application for Abundatrade.   The first release is a simple app that uses the camera to scan a barcode then sends the UPC to the Abundatrade server to get real-time prices that they will pay for used books, CDs, DVDs, and video games.    Functionally the app is simple and works well.    However one key element here is the primary reason we started with Cordova over other cross-platform tools like Corona, the camera.

Turns out that many of the cross-platform tools do NOT support the camera interface. That shot down Corona right away, which otherwise looked promising.

Cordova And Cameras

The nice part about Cordova is that the system is basically a wrapper for the native web browser.  That means coding in HTML5, CSS, and JavaScript.  It also has a number of third party plugins that hook native mobile functionality (via Java or Objective-C) to a JavaScript class.   In theory that sounds great.

Luckily there is a good camera scanner app that reads UPC,and other machine-enabled codes like QR, codes created by Google released in the ZXing project.  The ZXing applet is ported and ready to use for Cordova as a plugin.

Cordova Camera Caveats

The problem is that theory does not work out in reality.   The plugin for Android works wonderfully.  The plugin on OS-X, not so much.  Not surprising that a Google app talking through JavaScript to an Apple owned OS and development environment doesn’t work well.  Apple really does go through a lot of effort to put a stranglehold on their development pipeline.

The bottom line, we have yet to get the camera plugin to work on IOS4 or higher devices.   In theory the demo app works, but we’ve yet to see it on our iPod Touch or newer iPhones.

The Android Version of Abundascan is out, but we still are having issues with Cordova on IOS.

Our Second App

Our second app is a little less ambitious as it is testing the waters for a larger project.  This app is simply a screen that shows your current GPS location with exact latitude and longitude.   Where Am I Standing? is a free app that does just that.   To make it a little more interesting we wanted to add an info page with our name and logo and a little bit of graphic “window dressing”.

Again, here we ran into multiple issues.  This time noticeable right on the Android before we even attempted the iPhone release.    We want a simple app with no glitches yet there are several things that still aren’t right.  We can spend a good bit more time addressing in convoluted code to workaround quirky UI elements.  Others are as-yet un-fixable.

Technically it was easy & works well. Aesthetically it is NOT of the caliber I want it to be at.    As I dug deeper into this I uncovered a lot of hidden secrets about mobile app development and why 99.99% of these cross-platform tooks like Cordova fail.

The Compromises

Here are the “little details” that are compromises I don’t want to make.  I want to build QUALITY apps.  That means making them as perfect as we can, and this stuff is far from it:

Swipe Right / Left : I wanted to be able to simply swipe the main screen to see the info screen (“created by Cyber Sprocket”).     One swipe works, then it breaks.  This is a fundamental issue in the browser kit Cordova uses as the foundation for their solution.   Google developers refuse to address it saying it is “as designed”.

Vertical Page Scrolling : I don’t want ANY page scrolling, jitter, etc.   The pages are too “tall” and are scrollable if you swipe up or down.  This can be fixed but takes extra coding to do so.   What a pain.

Button Highlighting : Sometimes the highlights on the info/home buttons “stick”.  This is a built-in feature of jQuery Mobile and Cordova.  It is wonky at best.

Screen Hesitation: Even on a mid-range phone with just about the simplest app possible, sometimes going to the “info” page hesitates, same with going back to home.

Navigation History : Go to info, then back to home.   Each time you do this is adds to the “history”.  Do it a few times and your back button is loaded up with a bazillion loops of home/info/home.   Again, fixable with code (mostly) but why?


While Apache Cordova will help you build apps using technologies you likely already know like HTML5 and JavaScript, the implementation is far from simple.  Getting stuff to work on more than one platform requires extensive knowledge of all the quirks.  Like IOS requires a special onDeviceReady hook or it won’t even load properly.   The apps also feel “heavy”.    The UI is not responsive and, depending on the hardware, often misbehaves.

While Apache Cordova may be a great tools for building a functional prototype or possibly building corporate apps where users may value function over form, in my opinion Cordova is a compromise.

Yes,  you can probably build a well-polished UI.   But it takes a LOT of extra effort because you are hamstrung by the JavaScript/web interface.  Of course you can write custom Java or Objective-C hooks and/or make your own plugin, but isn’t that point to get away from native custom code?    You can also get around *some* of the quirks with a good bit more coding, but how you get around which quirks often requires intimate knowledge of the quirks for the particular mobile OS that is giving you problems.

I’m sure we can build quality apps with Apache Cordova, but this is not about CAN we do that, it is about what are the benefits of doing so.  From a business perspective there appears to be little gained here over a process that includes solid architecture, documentation, code design, and good old-fashioned cross-platform awareness and porting.

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 : Setting Up

Google App InventorIn the previous article I went over some of the notable items on the Terms of Service for Google App Inventor. Here we get into building our first simple app.

App Inventor and Java

While you don’t need to know how to code in Java, you will need Java installed on your computer. Don’t worry, your computer probably already has Java on it. If not, it is usually a simple process to install or upgrade Java on your system. It is not any more difficult than installing or upgrading Flash. That said, sometimes getting Flash or Java upgraded and installed can be a challenge depending on your computer security settings, hardware, disk space, memory, and other unique factors that require you to hire a Comp Sci major just to get started.

Notes about App Inventory and Java…

  • Requires Java 6.
  • Upgrading (or intsalling) Java can be a challenge on some systems.
  • Get Java at

Java Exposes It’s Ugly

Now that we have our Java environment up-to-date we can get started. Surf to your App Inventor login and launch the program. If everything is going well you can follow the Google tutorial and start creating your first app, a picture of a cat that will meow when clicked.

This is where things get ugly for App Inventor and Java.

There are 3 main parts to creating your App Inventor mobile app:

  • The App Inventory Palette – where you draw your interface by dragging & dropping components onto a mockup phone.
  • The Block Editor – where you drag and drop logic components using a puzzle analogy. In essence you are writing Java code visually.
  • The Phone – connecting your Android phone is your staging (or testing) environment to see how things really work when “glued” together.

All was going well. The palette came up, got the button, the photo, the MP3 file all in place. Got the phone connected and the PC loaded the device drivers for the HTC Incredible being used as the test device.

Ok… let’s start writing some code. Fire up Block Editor. And…

We get “Java Ugly” in full effect. While Java has some very cool things that deserve bragging rights, over a decade into its existence and it still retains the uglies UI contest hands-down. Not only do all default Java interfaces look like they were designed for a 1987 character based terminal, they are often less than helpful in helping you interact with whatever files, folders, devices, or web addresses you need to resolve a problem.

In my case the “command interpreter” that allows the App Inventor to talk to the phone cannot be found. The ugliness ensues:

"Java Ugly" Command Directory
“Java Ugly” Command Directory

Yikes. Welcome to 1987.

Fixing The Missing Blocks Command Directory

Turns out that I missed an important step before setting up my environment. Not only do you need to upgrade/install Java, but you also need a desktop program that Google App Inventor uses to communicate with the phone (among other things). The Windows version is here:

Next Problem : Windows And Google Not Playing Nice

The next problem we run into is that the Block Editor cannot talk to the phone. It just doesn’t see it. After reviewing the App Inventor setup program we learn that you should “not change the default installation directory”. Virtually every single app on my computer goes on my 500GB D: drive, NOT the default C:\Program Files directory.    Wow.  Really, “don’t change the default install location”. Back to 1987 I guess.

So we uninstall the application.  Re-install it in the default place.   All is good, right?

Well, not so fast. Now the Block Editor is looking in the original D:\ install location but it cannot find some of the necessary components.

Great. Copy all the components over from the C:\program files directory. Still not working. Uninstall and delete EVERYTHING. Reboot…  we’ll be right back…

Windows Serves Up EPIC Fail

We’ll be right back, my butt. On the reboot windows decided my Windows account no longer exists. I was immediately greeted with a rather useless “The User Profile Service failed the logon.” message as soon as I tried to get into my Windows account on my local PC. Great. Off to safe reboot & finding the answer.

Now for the favorite part of my app development experience. REGISTRY EDITING.

Yup, that’s right. To restore my account back to normal I had to edit the windows registry. What fun. Luckily that is all it took and the instructions I found on the Microsoft Support site actually worked. If you ever need to do this yourself, make sure you sacrifice the requisite number of goats then follow this link:

Try, Try Again

PC back online. Check.

Re-install the appinventor_setup_installer_v_1_2.exe.

Open up the Google App Inventor at Check.

Open up the Block Editor. Check.

Ohhh… wait… no devices found. The editor is open, but it can’t talk to my phone. The phone is in the proper USB debug mode. No communication with the device. Wonderful.

It turns out that the AppInventor_Setup_Installer executable that we downloaded (all 90MB) may NOT have the proper driver for the HTC Incredible phone, even though Google notes it as one of the phones that works with this development IDE. Now we need to go to the HTC site and find the right driver and try this all over again.

Just to make matters even more fun, there is no simple “HTC Incredible” device driver. However, even with the phone attached to my PC and visible as an external device, a visit to the Device Manager in windows shows it as an unknown device with a name like “ADB”.

Setting Up HTC Drivers for Windows

So here I am, no obvious HTC Incredible drivers. Some hints on the “Internet at large” indicate that the full blown 30MB HTC Sync application, WHICH I DO NOT WANT, will have a driver for the phone packaged up in there. I sure as heck hope it doesn’t mess with my already working perfectly Google Sync program that keeps my contacts, calendar, and email all perfectly in sync with the Toshiba Thrive table, HTC Incredible phone, and my Windows desktop. We’ll see.

For now, I sit and wait… going on 15 minutes now… for a 30MB file to be downloaded from what must only be direct via mainland China on the 宏達國際電子股份有限公司 (HTC Corporation in case you’re wondering) website. I’m on a 50MB/10MB line, but this is slow as heck. Must be getting interrupted by some goats, stray chickens, and a stray tank rolling over the fiber line before it tunnels it’s way under the Great Wall on the way to The States. Man this is slow. Guess I’ll go practice more guitar lessons while I wait…

…I’m back.

Installation of the HTC Sync program got the drivers. Sadly I had to start the installation, let it install Adobe AIR, the HTC driver, and some other junk then cancel out right at the start of the actual HTC Sync installation. At least I got out of that.

Next.. maybe we can code our first app.

Not So Fast…

Wow, this sure is a LOT of work for a supposedly easier way to develop Android mobile apps. I had Java, Eclipse, the SDK and my first mobile app written the “old fashioned way”, you know… with CODE and an tried & true ID like Eclispe, done in much less time than the 4+ hours getting this setup.

My intention was to write a quick article on actually using the App Inventor IDE, yet here I am writing about how to setup the IDE and how to install drivers and how to debug a failed Windows login.

So much for quick & easy.

Hopefully the next article will be about actually creating a usable app with App Inventor.  Stay tuned.

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

Mobile Phones Don’t Play Nice With WiFi

Now that Verizon has dropped their unlimited data plan it is time to follow up on the previous Droid Incredible Crashes WiFi Networks article. Since the Droid Incredible wreaks havoc on the home and office networks I often turn off WiFi on the phone. I do this so often that the WiFi on/off widget is on my home screen and is probably the most-used application on my phone. That is sad.

As sad as that may be, a much more troubling issue is now on the horizon… and by horizon I mean arriving TODAY. While I was perfectly happy scanning my email and checking the latest news on my phone via the 3G network this is now going to be  a very costly endeavor. Every megabit has now become very costly and thus I need to make a choice. Crash the entire local network and render it useless or pay a premium to have a network service that works.

It is time to take off the kid gloves and put on the boxing gloves. If Verizon is going to charge for every bit & byte then they sure as hell need to provide a phone that works on the WiFi network. I’m starting that battle today, we’ll see where it goes. Probably nowhere.

Check back here for updates.


Update : Verizon Unlimited Plans “Grandfathered”

Something of note from Verizon’s response to my email about fixing the WiFi on my HTC.  This certainly helps make the broken WiFi less of an issue as I constantly use 3G even when I’m in WiFi range due.

We understand your concerns about your device and new data plans. Please note that customers with unlimited smart phone data plans will be able to keep the data plans as long as the plan remains on the account. Because of this, existing customers with unlimited data plans are not required to select from the new data plans. 


Verizon Wireless

Data Technical Support 

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.