[Spirit FM] mikereidis:
I'm currently working on Spirit2.

I expect to GPLv3 sufficient Spirit2 code to create a fully working* FM app that will run on some** popular devices that are rooted or running custom AOSP based ROMs.

*"fully working" does not mean it will support fancy features such as RDS.

**"some" may mean some subset of Spirit2 supported devices. IE. I might release C source code for FM chip plugins only for Samsung and Qualcomm chips, while still providing a freely redistributable plugin for Broadcom, but without source. This is just an example; we'll see.

At this time I think I'd keep the code to myself for stock, unrooted devices running proprietary FM APIs. But I'd be happy to see free versions of Spirit2 in custom ROMs, built from source code I'll release.

I think the first "open source" I will release will be in the form of an App Inventor 2 app: http://newblocks.appinventor.mit.edu/

MIT's App Inventor (AI) was a Google project in early 2011 when I prototyped the first Spirit FM app with it. Spirit was quickly re-written in Android's Java because it was not possible at that time to create a professional app with AI.

Conceptually, AI is a pretty cool way for even non-programmers to create a graphical user interface using diagrams and lego like block connection concepts. Practically, you must at least be a logical thinker to do much with it, it still has many short-comings and there's a bunch to learn to work around those short-comings.

I'll be looking forward to see what other people may be able to do with different GUIs or things like RadioDNS or whatever. I'll be using the same plugin architecture as was proposed by ST-Ericsson, and as used by Sony on 2012+ devices. So others will be free to write FM chip plugins, if someone wants Mediatek support for example.

The App Inventor "source code" will include documentation on the Activity Intents and responses that were implemented so that the AI Activity Starter component could be used to interface with the Spirit2 FM APIs. A Java app could do the same as AI, or could go one level lower to the equivalent Service based API.

I initially thought to expose the ST-Ericsson proposed FM API, or a very close equivalent, and may still do so. But it seemed difficult to use, so I layered a simpler API on top, similar to as used in the current "Spirit1", and allowed this to be used simultaneously by multiple apps, their activities and services, as well as widgets, etc.

It works, but an app written to this API, STILL has to do a lot of "boring" service type stuff, and the app is still pretty complicated. So I built a Service Intent API that allowed much simpler UI type apps to use the services of Spirit2's main "app" service. In prototype form, this is working OK now, and is probably the best option for a 4th party Java based app that doesn't want to do all of it's own audio, media button, AVCRP, notification window, lockscreen, widget, presets and other configuration handling by itself.

Then on top of all that Service Intent API is the Activity API so App Inventor can ride on top.

I'm amazed at how many layers this can produce. It seems to work, and be a reasonable design, but it's time for me to sit back, count, and ponder:

- App Inventor (or Java App).

- App Inventor friendly startActivityForResult() Intent API (or Java App).

- startService Intent API + Intent Broadcasts to return results and update values such as RSSI, RDS, audio state etc.

- Simple Java based API with such methods as freq_set() and seek_start(). Audio functions are handled by plugins I've designed.

- Slight Variant of ST-Ericsson/Sony FM API.

- Sony 2012+ FM API or ST-Ericsson API

- NDK C code for FM chip plugin.

- At minimum, a Linux kernel driver API such as /dev/radio0 V4L. For stock, unrooted proprietary APIs, there is a whole new FM stack under here, with several layers.

I would open source code and documentation progressively, moving down the layers as the design firms up and the code becomes fit for outside usage.

Maybe in a week or so I could open the App Inventor prototype, and get more serious by year's end.