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.
Related
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.
I am currently planning the development of a multiplatform app, and I am not sure wich way to do it fits my requirements best, since all possibilties I could think of failed to satisfy me.
First I want to write an app for android, which should feel like a normal typical android app. So I want to use the standard actionbar and android design look and feel in my other gui elements. After finishing the android app I am planning on developing an ios app, which should have a different design, so i am going to redevelop the gui for this anyway.
But I don´t want to rewrite the other code wich represents the intelligence of the app, independent from the gui. I came up with the following possibilities:
1. Java GUI With native library
Here I abstract all the code of my app in a C++ library (since as far as I know ios supports the usage of c++ libraries too) and develop the gui android typically in java. The library would than have a function to start and would inform the gui about every change via callback functions.
Pro
I can reuse all the code that would be the same on both platforms. I just would implement the gui seperately
The design of the android gui is straightforward as I want it to be. It looks like typical android because it is typical android.
Cons
I dislike the usage of JNI very much. Especially the signature and names of the callback functions (calling java functions from c++) are not checked at compile time and require a lot of manual work. If I rename a function and forget to rework the native part I only notice this mistake at runtime.
2. Build the GUI on the native side
Here I had difficulties finding out what is possible, especially for 2.2
2.1 Use Qt
I have only a few first step experiences with Qt in general but as far as I understood i would have the following pros and cons:
Pro
Reuse most parts of the code for ios and Android. I would than redesign the gui for each platform to make them feel natural. I can´t evaluate how much qt may even assists me at doing that
Cons
I have to copy the android gui by using other qt widgets. This is more effort and I don´t know if one can replicate the android gui elements (like the actionbar) so that the user wouldn´t notice it.
2.2 Using the android framework from the native side
I dont know if this is possible at all, I wasn´t able to find this information. Can I use the class "NativeActivity" and use the android framework to build the gui and use e.g. the actionbar? If this is possible somehow it would have the pros from 1. and maybe wouldn´t have it cons?
Do you have any feedback to my ideas or maybe even new approaches I didn´t think of? How do other multiplatform apps like WhatsApp solve this problem? Do they have redundant code for each platform?
Thank you,
Tobi
I would say that it depends very much on your application requirements. By my opinion, a better solution is to develop a separate application for each platform using recommended SDK's for that platform, and implement in native C++ only the time consuming data processing algorithms.
Application runtime on mobile platforms is not so straightforward as on desktop platforms. You should take into account background and foreground processing, specific application life cycling, accessing system resources such as network, file system, etc. And all these issues do differ on iOS and Android.
Regarding possibilities that you listed.
Qt/QML is ok only in case two requirements are met:
1.1 Your application is a foregroud application without any background operations.
1.2 You purchase a commercial Qt license because only commercial Qt can be submitted to Apple iTunes app store (even GPL apps are under
question).
Using NDK Native Activities on Android with cross-platform C/C++ backend. Android NDK API offers much less API then Android Java SDK, so a lot of things you will have to implement or wrap manually. It is a hard road.
Mixing Java code and C/C++ using JNI gives you more of Android SDK API. But you should remember that an Android activity's life cycle is not somewhat that you're used to deal with when developing on C/C++.
Approach that we are using
We've been developing an application with a huge amount of cross platform functionality that should work on Windows/Linux/Mac OSx/Android/iOS. We're using the approach as follows.
Cross-platform core is written in pure C++.
We have adaptors to GUI interface for each platform.
On desktop we use Qt as it reaches all desktop platforms with minor adapting to each platform.
On iOS the GUI is built using iOS SDK with Objective-C and C++ core is linked as a Framework. Still, we had to patch our core in some way for iOS background requirements and so.
On Android we wrap our C++ core in a background process and build all the GUI using only Android Java SDK. Foreground GUI activities interact with the core via local sockets, so we don't need to bother with activities life cycling in our C++ core. But the adaptor is a litle bit complicated.
Nevertheless, both mobile platforms often require workarounds and adaptations in C++ core which add a number of #ifdef'ed branches in code for each platform.
I have eclipse Kepler and I am having "Android-Sdk-Windows" files. But I cannot able to make an android project in eclipse.. Do i need NDK necessary.
I already have experience with opening project with just "sdk" and eclipse.. But this times How can i enter the "sdk" path instead of "ndk".
Or Teach me what is "sdk" and "ndk"
i tried eclipse->preference->android-> But i can only see NDK location.
Native methods are platform-specific code. They are usually written in languages such as C or C++ and contained in libraries(dll's). It is possible to create a hybrid Java application that benefits from such libraries.
Reasons for Using Native Methods
Gaining access to special capabilities of your device or or Android
OS
Gaining extra speed
Gaining access to a large body of existing legacy code
Typically, good use cases for the NDK are CPU-intensive applications such as game engines, signal processing, and physics simulation
The major disadvantage of native methods is that you won't have cross-platform capability.
What is Android NDK
The Android NDK is a companion tool to the Android SDK that lets
you build performance-critical portions of your apps in native code.
It provides headers and libraries that allow you to build activities,
handle user input, use hardware sensors, access application resources,
and more, when programming in C or C++. If you write native code, your
applications are still packaged into an .apk file and they still run
inside of a virtual machine on the device. The fundamental Android
application model does not change.
Now if you don't know what native code is, then probably you don't need to use native code. Android NDK documentation explains this well:
..., you should understand that the NDK will not benefit most apps. As
a developer, you need to balance its benefits against its drawbacks.
Notably, using native code on Android generally does not result in a
noticable performance improvement, but it always increases your app
complexity. In general, you should only use the NDK if it is essential
to your app—never because you simply prefer to program in C/C++. When
examining whether or not you should develop in native code, think
about your requirements and see if the Android framework APIs provide
the functionality that you need.
Yo do not need the ndk, in order to build an android project. If you are having difficulties with eclipse, I would suggest using Android Studio unless you are dead set on eclipse. I use both, and strongly prefer to use Android Studio whenever I can.
If you decide to stay with eclipse, it is as easy as downloading the ADT plugin by putting the url in the input box under Help->Install New Software, launching and downloading the sdk from the Android sdk manager, restarting eclipse, and then starting a new Android project. Hopefully you do not have to do anything to configure java or anything else.
The ndk is a way of accessing things from a lower level, in order to bypass certain things, or squeeze more performance out of a phone for highly intense operations, or finally to be able to port c/c++ code from different project. i.e. You can write a Opengl ES game in c and reuse most the code for web, ios, and android this way. But that goes beyond the scope of the question, and this answer.
Firstly you should ensure you have installed ADT plugin .
I try to understand how Xamarin.iOS (MonoTouch) and Xamarin.Android (Mono for Android) work.
I wrote a little App and looked into the .app and .apk file.
Inside of the .app file (iOS) are many .dll files. But why?
On every page and post I read they say: The App is executed native and nothing is interpreted.
Can somebody explain to me what the xamarin developer mean with "native"?
Inside of the .apk file is not a single .dll file..
The Xamarin definition of "native" includes but is not limited to:
Every line of C# code is compiled to machine code and then packed in .app. There is no JIT at runtime, as it is suppressed by AOT. More information can be found at
http://www.mono-project.com/AOT
(Note that Xamarin.Android still uses JIT, http://xamarin.com/how-it-works)
Access to platform native types / API is fully open, so you are not limited to a small set of API calls (if you use HTML5 / JavaScript, you know what kind of limitations are there).
The user interface you design is bound to the native API exposed by iOS (CocoaTouch) or Android (Skia). There is no intermediate layer to hurt performance or look and feel.
As to what is inside .ipa or .apk, who cares? Of course #Jason's comment shows us of some internal implementation details.
First of all, Xamarin works on two different runtimes at same time:
Mono
Native runtime (Davlik, ART, iOS runtime)
Some example. When you are creating your own C# class in Visual Studio, instance of this class will run under Mono. Also when you are downloading Newton.Json package from nuget, this will run in Mono too. This is reason why we can use all cool .NET stuff. However, when you are inheriting from Java.Lang.Object (Android) or NSObject (iOS) or making a custom controll, instances of these classes will run under native runtime.
Second of all, you can noticed that we need bind these two worlds somehow. Let's have a look what type of objects do we have.
Managed objects (Mono)
Unmaneged objects (Native world)
Peer objects (Mono, objects which is wrappers for native objects)
Peer objects it's instances of Xamarin SDKs classes (for example activities, view controls, UILabels, TextViews and so on), instances of your own inheriting from Java.Lang.Object, NSObject, Fragment or even UISegment classes.
That mechanism is one of most important things from Xamarin.
PS: Actually, it does not matter which of compilation do we use for Xamarin projects JIT or AOT. It depends on platform and allows / not allows some features from .NET world. That does not describe how Xamarin works.
The Xamarin compiler bundles the .NET runtime and outputs a native (binary) ARM executable, packaged as an iOS or Android app.
I know that Go programs can be compiled for Android.
How can I use Android specific API, like getting GPS coordinates or opening a URL with the default browser, from within a Go program?
I'm afraid it's hardly possible at the moment. In the "Meet the Go Team" I/O sessions, the guys from the Go team stated that they have no plans to add Android support to Go.
What we have now is just a compiler for ARM architecture. Unfortunately, this is pretty much useless for real Android apps, though such programs can be launched from the command line on Android devices.
Most of the Android framework is written in Java, so to interact with it your code should be compiled to a *.so libary, that will be loaded and called via the JNI interface. And it's not possible with the current Go compiler (gc, not sure about the gccgo).
Maybe you will be able to make bindings to the Android NDK API with cgo, that would allow you to create applications in Go since API level 9 (Android 2.3)
UPD: You can now use JNI from Go and create java bindings automatically with golang.org/x/mobile package. In Go 1.4 it's still experimental, but there are plans to include it into Go 1.5 release. The package also provides bindings for GL, audio and user input (hopefully they would also add iOS support and that would be compatible for Android and iOS one day). Anyway this package is mostly oriented at writing games in Go, rather than using Go as a replacement for Java on Android.
Take a look at my answer to Android App from Go programming language. The goandroid project allows you to create Android apps in Go through the NDK.
(Disclaimer: I'm the author of goandroid)
Edit: As mentioned in the comments, Go 1.5 adds official support for Android apps in pure Go or as a mix of Java and Go. iOS is also expected to arrive in time for the final 1.5 release. See https://github.com/golang/mobile for more details.
GO 1.4 doc says, "Go 1.4 can build binaries for ARM processors running the Android operating system. It can also build a .so library that can be loaded by an Android application using the supporting packages in the mobile subrepository"
There is package app option in "golang.org/x/mobile/app" library that lets you write Apps for Android (and eventually, iOS).
Step 1: Create a platform independent GUI library using Golang that uses OpenGL to draw and an intelligent event and data-binding system to write the apps in. Any software using OpenGL is going to be more-or-less portable. Essentially, re-write Kivy in Golang.
Step 2: Create introspection/reflection based wrapper for using Java classes similar to PyJNIus (also a Kivy project).
Step 3: Lots more hard work, because there is a lot to do to get to the level of Kivy
Step 4: Profit