Do they share the code base and version number?
Does Google release the same piece of code for both and just use different flags for mobile phones and Android Things?
This may be a strange question, as I am particularly interested in Android Application Framework.
Do they share the code base and version number?
From an Android application developers's view point there is not much difference between Android OS and Android Things. I.e. you can successfully deploy an Android app developed for Android (OS version 7+) on a platform running Android Things.
Does Google release the same piece of code for both and just use different flags for mobile phones and Android Things?
No "flags" at all. It's rather a matter of adding new system (C/C++/Java) services specific to the supported platforms with its underlying hardware or removing the old ones, needed for mobile devices and not related to embedded systems. Actually Android Things is pretty much an inheritor of Brillo.
As a quick look consider the following overview of Android Things OS to see how it differs from Android.
With regards to the Android Application Framework, you can expect the vast majority of APIs to be the same on Android phones and Android Things. Specifically, this page details the APIs that are not available:
CalendarContract
ContactsContract
DocumentsContract
DownloadManager
MediaStore
Settings
Telephony
UserDictionary
VoicemailContract
Additionally, a few Google Play Service APIs are not available.
In terms of whether Google releases "the same piece of code for both" the answer is a bit complicated. Android's framework is a combination of a lot of files, some of which only make sense for specific form factors. Different build configurations state what files to include, which to not include, and how exactly to build the correct system image.
I don't know if this question fits with SO's question guidelines.
We are a small media company, that specialises in customising Android to add extra sounds effects to the AOSP platform code. We do this by modifying the AOSP's frameworks/av/media C++ code, and adding Java and resource code to packages/apps/Settings.
We work with several Android phone manufacturers in Asia. The problem that we encounter is that these companies are reluctant to give us a copy of their customised AOSP codebase, which is understandable, given their investment in IP. I was wondering if we could use the standard Google AOSP, plus a subset of the manufacturer's customisations, such as drivers and their precompiled libraries, to allow us to integrate out software locally onto their phone, and test this software locally before on-site integration / acceptance testing. Now we have to perform the integration on-site with no prior preparation, with the resulting last-minute problems and stress.
Is this possible?
Paul
I am attempting to learn more about mobile/tablet development and, as a .NET developer, I am naturally drawn to Mono. But I am confused--I thought that Mono was free and open source; however, all signs seem to point to Mono being a "pay-to-play" deal (https://store.xamarin.com/).
Can someone please help me understand which is the correct answer?
Thanks!
Matt
Update (2016/03/31)
Mono has been re-licensed to MIT;
The Xamarin.iOS, Xamarin.Mac and Xamarin.Android SDK are going open source;
History answer
First let's clear up the Mono case :-)
Mono is free as in free speech, not free beer. You can get it for free (i.e. without paying) as it is available under open source licenses that allow this. But you could still pay for it too (e.g. people did pay for some versions of Mono in Novell's days). Also some people cannot use Mono under the free open source licenses (e.g. as a game engine where the source is not available...). In such cases a commercial license, from the copyright holders, is needed.
Mono for Android is a commercial product based on Mono and sold by Xamarin (who has the rights to license Mono). It re-use a lot of what Mono has achieved and also brings a lot more features to allow .NET developers to use their skills on the Android platforms.
Finally evaluation versions of Mono for Android are free and fully functional when used with the Android emulator (not with devices). So you can still try, learn and enjoy Mono and Mono for Android without paying a dime to Xamarin :-)
note: the same applies for MonoTouch which allows you to build .NET-based iPhone/iPad (iOS) applications from an Mac OSX computer.
Disclaimer: I work for Xamarin
As a long-time .Net developer (starting with 1.0), I can tell you that if you are anything other than a hobbyist, any money you spend on MonoTouch and MonoDroid will pay huge dividends in the very short term.
There is a certainly a learning curve for the UI and the third-party control environment isn't anywhere near as robust as it is for the Windows platforms, but the ability to program against the .Net framework (even if the language is C#) is an indescribable advantage and well worth every penny spent with Xamarin.
We were able to port a 500,000 line VB.Net application written for the Tablet OS and PocketPC to the iPad in less than 3 months, including local database support, web services interaction, etc. And it should take us less than another month to create the UI for Android now that we have a common services layer. At that point, we will have an application that will have similar functionality across iOS, Android, Windows desktop, Windows tablet, and Windows Phone. I certainly can't do that with the tens of thousands of dollars that I spend per year in the Microsoft ecosystem.
Old post, but poupou's answer needs some clarification and some additional information.
First of all, since Poupou's posting, Xamarin has added a new Community Edition license to the entire Mono/Android/iOS stack that allows for closed source distribution of apps, but this license is restricted to how large the binaries can be. In practice, even some Hello World applications exceed the community edition binary size limits, so in my opinion this is not a real option by any practical definition.
That being said, the core Mono runtime and runtime libraries are licensed under LGPL. This makes it difficult to release closed-source software in an app store using the mono runtime without purchasing a commercial license from Xamarin, but not impossible. One option that the LGPL allows, according to my understanding, is to provide the object files for your app. This would allow a user to re-link your app's object files to a different version of the mono runtime and then install that relinked app onto their device. They would still have access to the object files, but you could still keep your source closed if you wished. I'm not a lawyer, but I think you may be able to charge for these object files and distribute them by request only.
If you want to release an open source application using mono, you would be well positioned to do so because you can of course release not just the object code but the full source of your app, allowing users to relink mono into their own version of your app, and thus fulfilling the requirements of the LGPL.
Now, here's the problem. While what I said above is true, it ONLY applies to the core mono runtime. That's because the core mono runtime has an open source license. You might be surprised to know that none of the platform specific BINDINGS, which are the libraries and developer tools that Xamarin provides to hook up your .net mono code to, say, the platform UI/system libraries of android and iOS, are open source at all. So, Mono for Android and MonoTouch (and monomac?) are neither free as in free speech nor free as in free beer. They are both 100% commercial products. Now, I'm told you can request an open source compatible license privately, but your open source project must be pre-approved, which means you will not be able to take advantage of the object code option for a closed source project, and I don't know what kind of restrictions Xamarin would place on such a license (I suspect similar restrictions to the community edition).
EDIT: Correction to the above - Xamarin won't give you an open source compatible license for an open source project. Instead, they will give you (as in, the developer wanting to release a build of an open source app on one of the app stores), a free full Xamarin license if they can verify that your app is legitimately open source. This is still the commercial license (for one developer), and not an open source compatible license, so this license does not apply to any other developers who download the code for your project and build it. They will need to purchase their own Xamarin license to publish their version of the open source app.
What this means is that, the only way to take advantage of the LGPL object code option for closed source distribution (or, indeed, to release an LGPL compatible open source app without Xamarin's permission), you would need to write all of your own platform bindings to make it possible for your app to interact with the system or UI in any meaningful way. Koushik Dutta, from ClockworkMod, originally started such a project, at least for the android bindings, prior to Xamarin's release of Mono for Android. He abandoned the project after Xamarin's release, but the code is still available here:
https://github.com/koush/androidmono
If one were to create a set of android/iOS bindings for Mono and release them under a permissive open source license like MIT/X11, then apps could bypass Xamarin and release apps under the object file option for LGPL compliance (or just release the code, if it's an open source app).
Going one GIANT step further - if you look at the core mono licensing breakdown, you'll notice that only the core mono runtime and its libraries are licensed under LGPL. Almost all of the class libraries are already using a permissive license like MIT/X11 or else some form of Apache or MS-PL. That means that if, hypothetically, in addition to creating some permissive open source bindings for android/iOS, someone were to start from scratch and rewrite the core mono runtime and runtime libraries (all the LGPL'ed parts of mono) using a more permissive license, then that hypothetical version of mono (I call it "MonoLibre" when I daydream about it) could be embedded in a closed source app, for free, without releasing object files, open sourcing your app, paying Xamarin anything, or having to ask Xamarin for permission to distribute your open source app. Xamarin could continue to sell the "commercialized" mono runtime, but MonoLibre could continue to use all the same class libraries and even the same compiler.
Mono itself is free. That doesn't mean everything written with mono is free. As is the case for mono for android. Somebody took the time to write software that makes mono work with android. Just because it's written in mono doesn't mean they have to share it for free. The only thing they'd have to share is any changes the made to mono itself. Just because android is free and open, doesn't mean I can't make applications and require people purchase them in order to use them.
It's been a while since this questions was first asked but I did come across a completely open source option called Monocross http://monocross.net/
Haven't used it so I don't know how good it is.
I have 6 months experience with Android, developing simple UI-based applications. Now I want to write applications targeting the Android core Kernel. For example, I want to develop a framework which is not present in Android. To achieve that, we have to write the code for the Kernel. I don't know where and how to start Android Kernel programming.
If anybody knows the way to start it please help me.
xda-developersA very awesome and very active place for anything smart smart phone related.
kernelnewbies
Generally good resource for starting out learning linux kernel(Which is what the android is built off of)
Building Android KernelAndroid Kernel Source
Linux kernel Online guide to driver development among many other related topics.
Update
For android source code you can check out one of the following...
or this question
or source.android.com
I personally dig this chrome plugin for browsing android source code.
If you are talking about platform level programming,i.e. framework extensions, native libraries and services there are a few places to start.
The first one is the new and updated official open source project page. The portions about contributing and porting provide some basic information on the platform architecture and what you need to work with the platform. The next step is to understand the build system for the platform and framework. There are some limited info available on the net if you google for it. The best way is probably to study some of the makefile templates available in the open source project in the build folder. For info on how to add your own modules using Android.mk files it is a good thing to study make files for existing projects such as the ones available in external in the open source projects.
Once you have gotten as far as the above. That is you know the basics of platform level development and how to build your own modules for the platform the next step is to study the framework extension example available in the open source project. Check out the vendor/sample/PlatformLibrary folder (edit, as of 2.2 the vendor stuff has moved to the device folder) in the open source project and read the readme file, study the code, build it and make sure you understand it. If you don't then JNI, shared libraries, the platform security model and the core framework are areas that could help you out.
I guess that since you are talking about kernel programming you are also looking for ways to hook up new hardware with the platform and expose that functionality using your framework extensions to the applications. Hardware is basically added as a standard Linux driver so getting it to work under Linux is a good first step. How to hook it into the Android framework after that depends on what type of hardware it is. You could either use a native process to control it (compare the camera service or radio daemon in the current platform) or just spawn a thread in the application that uses your framework extension. For hardware that does not require that much attention plugging it in using an Android HAL library could also be an option.
I hope that provides some initial pointers on where to look. The official mailing lists are otherwise the main source of info about platform level development. Especially Android porting and Android platform.
You should also check out http://pdk.android.com. I just found this site recently and it is extremely useful. I wish I knew about it sooner. I'm not sure how dedicated Google is to updating the site because as BMB mentioned the vendor stuff was moved to the device folder in 2.2 but there have been no changes to the PDK site to reflect that. Also, some of the links don't work but I was able to find all the pages by doing a site search in Google.
The best and very first place to start would be Google’s documentation on android
https://source.android.com/docs/core/architecture/kernel
Then kernel building
https://source.android.com/docs/setup/build/building-kernels
Xda isn’t so great for kernel creation but is good for kernel modification and backporting. Mostly what they do there is provide newer versions of android to older phones rom modification and changing the battery animation in the boot.img
Google also goes over the development of new things for an existing kernel.
It’s best to start at the begining,
Personally I started at xda and went backwards which took WAY longer and just complicated my setup process.
This is my first S/O question, please be gentle!
I'd like to know more about porting C applications to native ARM for use on Android devices.
I can make simple programs using the prebuild toolchain which comes with the source, but how can I use this toolchain with applications which are more than one file and require configure and make?
This article explains it quite well:
http://davanum.wordpress.com/2007/12/09/android-invoke-jni-based-methods-bridging-cc-and-java/
Basically, you create a shared library like you normally do, wrap it with JNI and call it with native methods from Java.
At Google I/O they talked about introducing an "NDK" -- native development kit -- that should simplify the process of creating applications that use native (C) code.
It's worth noting a couple of things before you go too far down this route:
The NDK will provide limited functionality. It will be primarily intended to offer a way to run extremely time-sensitive code natively, but won't have access to the full system, nor will it provide an alternative application development model (you'll still need to write most of your app for Dalvik).
You can write native apps without the NDK, but you won't be able to distribute them to end-users using the conventional APK application package supported by the app store. It's really only a viable option if your app is being distributed as part of the carrier / OEM build - and even then isn't recommended.