One fundamental principle in AAP is that it aims to be a liberal framework that no one has to pay for AAP even for commercial uses. So, commercialization on the framework, including MIDI device support, is not going to happen, as long as I am the primary developer. But it is an essential question that I haven't figured out how to answer yet, as I don't work for any company for now and I should either work at some company or launch a business to get income, at some stage. It is important for the project on sustainability. It is technically possible to release JUCE integration under a dual license with GPL and commectial just like JUCE, but I would rather find that potential market like those vendors would need myself to help porting, which would result in a lot more income than just licensing (which I don't find I can live just on it anyways). That is not really a good business idea, as I want to make things as simple as possible so that people don't need me to adopt it. To be honest I had been refrained from announcing the project a lot, because plugin framework like this has to provide stability and AAP is not quite stable yet. I'm changing my mind on that because stability can be achieved through the public API like this MIDI device service, which is rather a recent addition to the framework. This entry reflects the idea of making it more public and reachable. Potential wise, there have been couple of inquiries on AAP from commercial and non-commercial Android audio and music app developers that want to expand their capability. I would be able to provide better pluggability for those folks at some stage. But if I do it now, that would involve too tight integration into their apps, and would result in annoying individual plugin app distribution that would kill openness of AAP. Inquiries and seeks for potential use of the plugin framework is still highly welcomed, of course.