"As everyone is trying to guess whether the next big Android update is going to be Key Lime Pie or not, and whether the release will be Android 5.X or 4.X, we have yet to hear anything concrete. After getting a tip from an eagle-eyed reader (thanks, deepayan!) and digging deeper, I can definitively tell you that Google is currently working on Android 4.3, and it is still Jelly Bean." Great detective work by Artem Russakovskii.

2. No it is not. It makes use of a Trace JIT, only compiling hot code. Too much information to paste here.

3. This is not true:
- You are creating a .so that is called by a pre-defined Activity written in Java
- You have communication between Java and C/C++ code happening via JNI calls and UNIX pipes for events, instead of direct OS calls

Since Android 2.3 the only new API is for OpenMAX AL, for everything else you have to wrap it yourself via JNI.

Thus you pay the price of interop every time you call an Android API or are notified from system events in a so called native activity.

4. Personally I don't care about Objective-C. But since they have clang, at least
they could allow iOS developers to easily port their application code, and not go
out of their way to forbid it.
So what if the UI code news to be different?

5. Yes, but the ticket I opened seems not to go anywhere. Android team requires shared objects and the Go guys hate dynamic linking with passion

3. Considering why NativeActivities were created and the main language of Android you will not get rid of that. Same issue as with calling Objective-C from C++, there will have to be a converting step somewhere.

4. And what would be the point of porting application code that is highly dependent on iOS frameworks?

That is not the same as you don't have to endure a JIT overhead. That is the reason .NET is compiled to native code in Windows Phone 8.

3. Considering why NativeActivities were created and the main language of Android you will not get rid of that. Same issue as with calling Objective-C from C++, there will have to be a converting step somewhere.

There is no conversion going on with Objective-C vs C++.

Both languages have native compilers available, and you can even make use of the Objective-C++ compiler mode.

There is no interop performance penalty between language implementations.

4. And what would be the point of porting application code that is highly dependent on iOS frameworks?

I don't know, code reuse? GNUStep also offers quite a lot of similar APIs.

Additionally it is always a matter of how much care is taken writing portable code.