If you want people to develop something, come up with detailed specifications. I read the thread, but I cannot write a program deciding whether or not a given candidate program fullfills the specifications currently.
Write down things like how the UI should look like, exactly in which ways you want to interact with the device, etc. If you don't care about a specific UI, it means that an addressbook with contacts with bitcoin addresses is not included for example and that it could look butt ugly. We generally want happy clients, but we also cannot guess exactly what you are willing to pay for (which is often different from what can be made).
There is a reason people developed UML. It is because one can point at a document saying "this is how we want you to document the requirements". Now, I don't need a full UML spec and I don't expect you to be able to write one, but you should be able to write a coherent story explaining all the features such that for everyone contributing to this thread it is clear what is going to be developed.
I also recommend you to define the abbreviations that you use to make it a self-contained description. I have used bitcoin, but for example I was not aware of bu.mp (it does look fairly interesting, but also a bad idea as there is a central server). The bu.mp requirement and a gplv3 license already seem to be incompatible (read the bu.mp license agreement). I think technically you can distribute something as gplv3 and calling a proprietary API, but it's rather messy, legally speaking.
What does 'creating a transaction mean without internet access'? The way I read it is that you just want to store a transaction like 'MOVIE TICKET - 5BTC - <address of receiver> <source address>', which you can later retrieve again by listing all such transactions. That's the level of detail one needs before one starts development as an example.
That way you can say before a single line of code is written what a sane way is to present the UI for example, whether it is even possible to make it run on a specific version of Android (another thing which was not specified), whether the (unspecified) performance characteristics are even possible on device X (what is the reference device).
In short, as in most software projects, the client is not clear about what he wants and in this case there are multiple stakeholders, which requires you to get to a consensus of what you want. First figure out what you want, then ask again.
