Develop Reference

What is the definition of Android Native Code?

I always see the term android native code here and there but not sure what exactly it is. So which part of android is android native code? Are Application, Activity, Fragment, View, Looper android native code?
More context: I'm trying to understand the shadow in robolectric tests, and in the doc it is said that "Android native code cannot execute on your development machine", so I'm wondering are classes like Application, Activity etc android native code referred here?
http://robolectric.org/extending/

The word native in Android development is overloaded.
Going through link you provided for Robolectric:
There are limitations however:
Native code - Android native code cannot execute on your development machine.
Out of process calls - There are no Android system services running on your development machine.
Inadequate testing APIs - Android includes next to no APIs suitable for testing
Roboletric fills these gaps with a set of classes known as Shadows...
So in this case the Android native code quote either refers to:
The Android Framework classes like Activity,Fragment,View where with only the Android SDK apps needs an emulator or device to run. But Roboletric bring its own Android Framework code which can be 'enhanced' by 'Shadows' for testing apps.
OR
The Android Native Development Kit (NDK) which uses Java Native Interface (JNI) to allow Java/Kotlin code to access C/C++ code for performance or compatibility reasons. So with Roboletric you can't call into JNI code, or at least not without some effort.
Later that same page:
Using byte code instrumentation Robolectric is able to weave in cross platform fake implementations to substitute for native code and add additional APIs to make testing possible.
The substitute for native code refers to Java/Kotlin APIs belonging to the Android Framework which Roboletric is substituting for to provide a test environment. Again, those would be the Activity, Fragment, View, etc. you were referring to.
The usage of the term 'native' in this case is similar a developer using a third-party app building framework like 'React Native', 'Ionic', 'Flutter', 'Xamarian', or 'Cordova/Phonegap', they may use a custom component written in Java/Kotlin as a native component to achieve some function which can only be done by direct interaction with the Android Framework but not in the language/API of that third-party framework like Javascript, Dart, or C#.
Java and its kin (Kotlin, Scala, etc.) refers to calling C/C++ code as native via the Java Native Interface (JNI) and on Android is facilitated by the Native Development Kit (NDK). Third party app development frameworks that sit on top of the mobile framework will refer to calls into the original mobile framework as "native".
Sadly as this is part of the terminology used in mobile development so a careful reading of the use of the word "native" is required.
Personally I would prefer if documentation using the word native included the language like native Java/Kotlin APIs or native C/C++ APIs as the first instance in the linked page had me going back and forth about the author's meaning.
Follow up to questions in comments
You mentioned that "they may use a custom component written in Java/Kotlin as a native component", you are referring to Activity, Fragment etc when saying custom component, right?
In that particular section I was referring to third-party app frameworks calling into classes that are Android Framework or directly call parts of it. Normally those third-party app frameworks already wrap/expose Activity, View, etc. but you as a developer may need a library or other custom Java/Kotlin code which can be invoked by the third-party app framework language (Javascript, Dart, C#). From the perspective of the third party app framework the 'wrapped Java/Kotlin library' is a native component as it is "native" to the mobile environment. That wrapped library code isn't written in Javascript, Dart or C#. Again the meaning of "native" is overloaded.
In the first paragraph of link, the author is emphasizing that we will run "real Android code" in robolectric. But as we analyzed, robolectric is shadowing the basic building block like Activity, Fragment, which seems contradictory to me, so the only explanation I can think of is that the ShadowActivity is wrapping the original implementation of real Activity, do you think that is the case?
Yes, the ShadowActivity is "wrapping" the original implementation of real Activity, I would take note that the author states: Shadow objects are not quite Proxies, not quite Fakes, not quite Mocks or Stubs.
It is important that shadow methods are implemented on the corresponding shadow of the class in which they were originally defined. Otherwise Robolectric’s lookup mechanism will not find them (even if they have been declared on a shadow subclass.)
and
Shadow class inheritance hierarchy does not always mirror that of their associated Android classes, it is sometimes necessary to make calls through these real objects so that the Robolectric runtime will have the opportunity to route them to the correct Shadow class based on the actual class of the object
So regular Java inheritance isn't quite the correct mental model for Shadows.

Android native code is not Java or Kotlin. It is not some classes like Activity or Fragment. Android native code is C/C++. Here is a bit of info about SDK(NDK).
And here you can find general overview of NDK(native development kit).
Hope it helps.

Creating android application without Android framework

In Android Stack 4th Layer is android Framework which uses JAVA,Kotlin. If I am correct than all applications are made from this framework.
Is there some other non JVM-Language based framework from which I can made Android Apps ?
I tried QT, But It also creates some java files and uses android Framework. Is it even possible to make Android app WITHOUT EVEN ANY PRESENCE OF JAVA ?

If your objective is to simply not write in a JVM language, you are welcome to use C/C++ with the NDK, using NativeActivity as your entry point.
If your objective is to avoid the framework classes entirely, you are welcome to build your own fork of Android that contains your own code as native Linux daemons, launched by init scripts or something.
If your objective is to ship an app on the Play Store or through similar channels that avoids the framework classes entirely, AFAIK there is no option for that.

You can not create an android application without using android framework. At least, for launching your application you will have to use framework functions from "android.os" package.

How are your experiences with NativeScript?

Does anyone have experience with NativeScript and can compare it to developing native apps, especially for Android?
I have read all these articles:
FIRST THOUGHTS ON NATIVESCRIPT
SECOND THOUGHTS ON NATIVESCRIPT
Introduction to Native Script – Is It Worth Your Time?
My Experience Developing with Telerik NativeScript
I know especially three of them may be outdated. But I want to ask all of you developers:
How is your experience with NativeScript?
Are there any Android-Components you cannot use? Which are these ones?
Is styling really so limited?
Do apps really look so different at runtime as in the mockup as in the pictures of the first article referenced above?
Does loading of native Android objects into JavaScript Code always work correctly?
Does NativeScript generate Java-Code for Android-Platform out of the NativeScript code I write?
Is it possible to modifiy this code if I want to use some native-only features? What if I want to make UI changes then? Do I have to regenerate the code and do I miss my native extensions then?

Very glad to see that you are evaluating NativeScript to eventually use it in present and future projects.
I'll try to condense answers to a few of the questions into one, as they really are mostly related.
Skipped.*
That depends on what has already been exposed through a custom view/plugin or module. The core-modules that every NativeScript app comes with contains the most basic of wrappers for both Android and iOS under a common API. There are plugins (nativescript npm modules) that provide additional wrappers on native android views (nativescript-telerik-ui for one, nativescript-carousel), most of which are created by the NS community.
As RexSplode mentioned before me - it's mostly the platform that imposes certain limitations. NS uses CSS to declare style, but you can also access the native components and manage their style and appearance programatically if what you need isn't readily available out of the box.
First I'd like to note that the first 3 articles you've linked are over a year old now, and trust me, NativeScript has evolved a lot since then. With all the available components (remember the npm modules I mentioned earlier?) there's a good chance that you will get a close to 1:1 similarity to a well-styled native Android mockup.
At build time metadata is generated for the Android/Java public API used in the project. When the JavaScript Engine (V8) fires up, that metadata is loaded into memory, prototype chains are constructed, and callbacks are attached, so that when you call new android.widget.Button(); in your JavaScript code, the proper virtual machine instructions will be called, and a native button will be created. Static methods are accessed similarly, check out the official docs to get a better understanding of how it all works.https://docs.nativescript.org/runtimes/android/advanced-topics/execution-flow
and 7., and a cont. of 2. Java code, or rather compiled Java code is generated whenever you wish to extend a native Android class that isn't available already in a module or in the native Framework. Extending classes is very similar to how you would do it in Java - you extend a class, and create new implementations of interfaces. That means that you won't have to open Android Studio to create a new class, build it into a native plugin and then add it to your project, since you can do it all in your NativeScript code using JavaScript/TypeScript. https://docs.nativescript.org/runtimes/android/generator/extend-class-interface
Disclaimer: I am on the NativeScript Engineering team

I investigated the Native Script a little and my colleague at work writes an app with it, so I can offer you a bit of information that I have.
1. skipped
There are limited amount of components you can use with native script out of the box. However, if you have a native-java developer who can write a wrapper for you - you can use everything.
It is limited to the platform you are using. Android itself has a lot of style limitations which cannot be easily overwhelmed.
don't know
It works a little different. Your JS object, or rather widgets are translated to java code. So with the items from the box - yes, they are okey. If you write a wrapper for your custom component, then all is up to you.
Yes it does.
No, the code is generated, how are you going to modify it? Changes will be undone on the next build. However, you can write a native module for your application and use any features you want. It is like defining an interface, which you can use in JS code afterwards.

MonoTouch / MonoDroid Service Layer incompatibilities?

We've begun to build Cross platform Android/iOS apps, having built exclusively in MonoTouch before. We're evaluating MonoDroid.
Our apps need to consume JSON and we'd like to use ServiceStack. Xamarin has a ServiceStack branch which we're using - https://github.com/xamarin/ServiceStack
We'd like to have a common project responsible for GETting and POSTing JSON. ServiceStack by Xamarin has different DLLs for Android and iOS. How do we have a single project and use ServiceStack to get at our JSON?
We're open to other options to get at JSON in a unified way?

By and large, managed *.dll's compiled for MonoTouch that don't have a dependency on MonoTouch specific types are compatible with Mono for Android projects.
ServiceStack is a great example of this. I've personally used it for multiple projects across the Xamarin mobile framework offerings.
As a general rule I tend to encapsulate all invocation to my web services using a partial class with async methods, like FooProjectRestClient. And then if there ever is any sort of segmentation that needs to occur it can happen in a shared class using #if defs.

The reason why there are MonoTouch and Mono for Android specific libraries is often because of the (smaller, Silverlight-like) profile available (e.g. things that depends on new FX4.0 features needs to be cut out). They are often the same code re-compiled with SILVERLIGHT (or MONOTOUCH, MONODROID) defined.
The reason for MonoTouch only specific librairies are generally because its environment (iOS devices) do not allow JIT'ing. So there's no code generation (e.g. System.Reflection.Emit) or dynamically (down)loading code... However it's often possible to provide (less performant) workarounds or skip a few features and keep a special version of the library for MonoTouch.
Now back to having a single shared assembly/project. The special MonoTouch assembly (generally the same code re-compiled with MONOTOUCH defined) is still a valid .NET assembly and often can be used in Mono for Android, Mono or .NET (once recompiled, even with MONOTOUCH). It's definitively not optimal but it's something you can try.
Another one is having the same projects (e.g. MyLib), across several solutions (e.g. MonoTouchApp, M4AndroidApp) and use special configurations (just like there's an iPhone|Debug one) to set different defines (e.g. MONOTOUCH on iPhone*|*). That can allow you to keep the best feature implementation in each platforms (e.g. in case the same feature is implemented differently).
I would try the later first (config), then sharing the MonoTouch special assembly and finally (if it really does not work) look for other alternatives.

Android NativeActivity

The Android NDK has just been significantly expanded to include support for writing android applications entirely in native C/C++ code. One can now capture input events on the keyboard and touch screen using native code, and also implement the application lifecycle in C/C++ using the new NativeActivity class.
Given all the expanded native capabilities, would it be worthwhile to completely bypass Java and write Android application in native code?

The NDK is not native per-se. It is to a large extent a JNI wrapper around the Android SDK. Using NativeActivity gives you a convenient way of dealing with certain app-life cycle events, and add your own native code on top. ALooper, AInputQueue etc. are all JNI wrappers of the Java SDK counterparts, some with additional code that is private and unaccessible for real apps.
When it comes to Android development, there's no such thing as writing an application entirely in native C++ - you will (in every real App case that I can think of) always need to use the Android API:s, which are to a huge extent pure Java. Wether you use these through wrappers provided by the NDK or wrappers that you create yourself doesn't really change this.
So, to answer your question: No, it wouldn't be worthwhile, because you would end up writing JNI wrappers for SDK calls instead of writing JNI wrappers to your own Java methods that do the same thing, with less code, simpler code and faster code. For example, showing a dialog using "pure c++", involves quite many JNI calls. Just calling a Java method through JNI that does the same thing will give you faster code (one JNI call), and, arguably, code that is easier to maintain.
To fully understand what you can do, you really must examine the Android source code. Start with native_app_glue.c, which is available in the NDK, then continue with the OS implementation of AActivity, ALooper, AInputQueue etc. Google Code Search is a great help in this. :-)
If it is easy to do in Java, and includes many calls, call a method through JNI that does it all, rather than writing all the extra code to do it with multiple JNI calls. Preserve as much of your existing C++ code as is reasonable.

Not if you are just making a standard application. The Java SDK is more complete than its Native counterpart right now so you would still be making things more difficult for yourself.
If you are not doing something that requires the NDK (read: real time performance sensitive) then stick with Java.

Just some food for thought but if you have an app on iOS and Android, some C/C++ code might be shareable. Obviously the iOS Obj-C and platform specific code wouldn't work elsewhere. (Ditto for the Android specific stuff). But you might be able have some shared code that's platform neutral.

If you can, stick with the java style apps until versions of Android supporting native activities constitute a significant fraction of the installed base.
For things that were hard to do before - particularly ports of existing code - this will probably be a big help.
It's not entirely clear yet what has changed vs. just writing your own thin java wrapper. For example, is there still a copy of the dalvik VM hanging around?