I have an Android app that serves as a GUI to a little daemon (written in C++) that needs to run on an variety of mobile/embedded linux devices. The daemon needs to collect GPS data and pass it to several clients (android phones, each with a GUI). The daemon needs to be capable of running on one of the same Android devices that is being used as the GUI, but I'm having a lot of trouble accessing GPS data from the C++ daemon.
I've looked into two options so far:
1) The "stay native" method: I've heard that gpsd exists for Android (such as here http://esr.ibiblio.org/?p=4886), but it seems elusive and/or not existent on my Samsung Galaxy SII, running Cyanogenmod 10.1.3-i9100 (Android 4.2.2). My standalone toolchain built from the NDK doesn't seem to have anything gps-related at all, even though sites like this one (http://www.jayway.com/2010/01/25/boosting-android-performance-using-jni/) indicate that java uses JNI wrappers to use C code to talk to the GPS anyway.
2) The jni method: GPS seems really easy in Android Java applications, so I started looking into the JNI (I'm pretty new to Android and Java, by the way). It is supposed to proved a way for C code and Java code to interact, right? I read up on it at this site (http://journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/index.html) and this site (http://journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/index.html) and a bunch of others. But it occurs to me I haven't seen any C code using the JNI that has a main() function in it. Also, the JNI_CreateJavaVM() function is commented out in the jni.h header file of my NDK toolchain. In fact, I can't figure out how to have a valid JNIEnv* in the first place. The conclusion I've come to is that JNI code is meant to be used by Java applications that need C support, not C applications that need Java support. Is that correct?
And then I have a third thought, which I don't like very much:
3) the "backup" method: In the instances where the C++ daemon is running on an Android phone, perhaps it could ask the android GUI for GPS data, then broadcast that to the other clients? I'm thinking they might communicate through a socket or something simple. This seems like a really ugly solution though, because on top of seeming inefficient, the daemon should be able to run independent of any GUI, but now it would depend on the GUI for GPS data.
So my real question is, has anybody else ran into this problem and found a suitable answer? Or perhaps there is something I am not understanding something aobut gpsd in Android, or about JNI in Android?
Thanks for reading.
I would recommend you to try to use this code: Android GPS using libhardware.
This small project use libhardware library from AOSP. See gps.h for more information about how to use GPS abstraction interface. Also worth a look GpsLocationProvider.java and com_android_server_location_GpsLocationProvider.cpp.
Related
As an experiment, I have a pure Qt C++ application (without QML) compiling (with cmake & ninja) and running on:
Windows
macOS
Linux (ubuntu and centos/redhat)
FreeBSD
It uses basically QMainWindow, QGraphicsItem and QDialog, iostream and a few C++ containers and iterators.
I am wondering if the port to Android is:
possible
easy or complex (if possible)
and if there are examples online
The same with iOS.
Yes, it is possible. I have worked in many Qt apps developed for iOS and Android. However, never used cmake, but qmake. it is good that you started experimenting using cmake which is the future as qmake is going to be deprecated sometime in the future. Qt's official documentation started adding cmake getting started tutorial.
https://doc.qt.io/qt-5/cmake-manual.html
I would like to suggest to use Qt Quick for GUI on mobile devices.
Technically, it's possible:
It's easy to compile C++-Qt applications for both Android and iOS.
For iOS, you'll still need a Mac with Xcode.
Deploying, debugging, and running the app is quite simple and seamless, too.
Practically, it's a horrible idea to try to port the GUI of a non-trivial desktop-application to mobile.
Graphical user interfaces designed to be used with a large screen, mouse and keyboard just don't work well on small touch screens.
Since you've mentioned QDialog: Some concepts work very differently on mobile compared to desktop.
E.g., Dialog is replaced by Activity and users usually don't deal with files.
You can (I've done it), however, design a Qt GUI-application without any QML, that works well on small touch screens and is at least usable on desktop.
It requires a lot of manual tweaking and hacking, but It's possible.
Notes:
qmake is easier than cmake for mobile apps (that should change in future)
although Qt has some abstractions, you'll probably need some platform-specific code (i.e., JNI, snippets of Java and Objective-C and many #ifdefs)
We are looking for a way to protect our code and obfuscation is not enough.
Is it possible to compile Android java code to a native Android library?
Another option would be to write the code in c and connect with it through JNI ourselves. But the code we have is quite elaborate and well tested, a rewrite to c would start the testing all over.
PS: Before we were running on x86 hardware and used Excelsior Jet as a means for protection. As we want to move to more cost-effective (cheaper) Arm/android hardware we are looking for a simular solution as Jet, which alas only compiles to x86.
In theory you should be able to use LLVM. It has:
A Java frontend
A C backend
In principle, this could do what you need. However I imagine you'd need to distribute (in compiled form) lots of the Java class library. All in all, it sounds really hard. And someone who really wants to read the code won't have too much problem with ARM disassembly...
I'm going to implement aodv protocol as a linux module for a research project, and I need to implement it on Android later.I wonder if I could compile my codes into the android kernel and have my module work as in Linux (kernel 2.6 up).
Any suggestions would be greatly appreciated.
(P.S. There are already some aodv implementations on Android, such aodv-on-android and UoB JAdhoc, however, those are implemented in Java, not involving kernels)
The tagline goes: Android is Linux, so anything (portable) you do on Linux should be simple to make happen on Android.
This is mostly true, however there are a few things you'll want to keep in mind:
Portability: If you're writing your implementation on x86 and then moving the module to ARM for Android, be careful not to use any capabilities that don't exist on both. However, for something like a network protocol, you probably won't be running into a lot of these. The only one that comes to mind is the NIC.
Dalvik: Generic Linux distributions tend to run fairly close to the OS, meaning they regularly make system calls or libc calls, and the semantics of interactions with the kernel mostly carry over to the application. Android, however, has essentially a Java environment build on top of that, and the majority of applications only interact with that framework. For you, this means you will want to be aware of the possible need to modify the Android framework in order to make changes visible to applications.
The above point depends on your use case, however. If you plan on augmenting routing for existing applications to use aodv, then you'll want to hack around with Dalvik. If you'll be writing one proof of concept application, then you can write the portions that interact with aodv in C using the NDK, and avoid having to modify the application framework.
You probably already know this, but the kernel built system is sophisticated enough that you should be able to get away with writing your module once and compiling it for two architectures or platforms just by changing your configuration.
Hope this helps.
Forenote: This is an extension of the thread started on /r/haskell
Lets start with the facts:
Android is one awesome Operating System
Haskell is the best programming language on the planet
Therefore, clearly, combining them would make Android development that much better. So essentially I would just like to know how I can write Haskell programs for the Android OS. My question is:
How can I get a Haskell program to execute/run on the Android OS?
How you do it is by first getting a Haskell compiler which can target C with the android NDK which comes with a GCC port for ARM architectures. JHC can trivially do this with a very small inf style file which describes the platform (word size, c-compiler, etc) I've done this with the Wii homebrew dev kit and it was quite easy. However jhc still has some stability issues with complex code such as using a monad transformer stack with IO but jhc has been improving a lot over the last 6 months. There is only one person working on JHC I just wished more people could help him.
The other option is to build an "unregistered" port of GHC targeting the ndk gcc, this is a lot more involved process because GHC is not a true cross-compiler at the moment and you need to understand the build system what parts you need to change. Another option is NHC which can cross-compile to C, like GHC you need to build nhc targeting a C compiler, NHC does not have many Haskell extensions like GHC.
Once you have Haskell compiler targeting NDK GCC, you will need to write bindings to either the android NDK JNI glue code framework (added since android 2.3) or you must write JNI glue code between Java-C-Haskell, the former option is the easier solution and if I remember correctly might actually be backwards compatible with previous versions of Android below 2.3.
Once you have this you must build Haskell code as shared library or static library which gets linked into the NDK java glue code (which itself is a shared library). As far as I'm aware you can not officially run native executables on android. You could probably do it with a rooted phone, thus I assume this means you can not distribute native executables on the app store even when the NDK gcc port can generate native executables just fine. This also probably kills the option for using LLVM unless you can get the NDK JNI working with LLVM.
The biggest hurdle isn't so much of getting a Haskell compiler for android (which is still a big hurdle) the biggest problem is that some one needs to write binding APIs for NDK libraries which is a huge task and the situation is worse if you need to write android UI code because there are no NDK APIs for this part of the android SDK. If you want to do android UI code in Haskell somebody will have to write Haskell bindings to Java through JNI/C. Unless there is a more automated process to writing binding libraries (I know there are some, they are just not automated enough for me) then chances of some one doing it are quite low.
L01man: Is there a tutorial about how to do this? For the
first part, I understand I have to download JHC. What do I have to
write in the inf file and how to use it?
Please note before I answer this question I haven't used jhc for quite sometime since I originally wrote this and newer versions have been released since so I do not know how stable jhc currently is when it comes to code generation of more complex Haskell programs. This is a warning to anyone before you consider making a large Haskell program with JHC, you should do some small tests before you go full on.
jhc does have a manual http://repetae.net/computer/jhc/manual.html and a section on setting-up cross-compilation and .ini file with options: http://repetae.net/computer/jhc/manual.html#crosscompilation.
L01man: The second part is an alternative to the first. I don't know how to do what you said in the
third.
Before you begin you should have some knowledge of C and be comfortable with using the Haskell foreign function interface (FFI) and tools such as hs2c. You should also be familiar with using the Android NDK and building .apk with shared libraries. You will need to know these to interface between C-Haskell, Java/C-Haskell and develop Haskell programs for Android that you can officially distribute/sell on the market store.
L01man: I understand that its goal is to create a binding for the
Android API. But... does the 4th part says we can't make .apk with
Haskell?
.apk is just an app package file format and is built with the tools that come with the Android SDK (not NDK), this has very little to do building the binaries itself. Android packages can contain native shared libraries, this what your Haskell program will be and the native shared/static libraries are generated via the Android NDK.
A language that has recently come to my attention is Eta.
Eta's compiler is a fork of GHC 7.10 which has a JVM backend. It is possible to use the generated JAR files to write Android apps and even use its Foreign Function Interface to call native Android Java libraries.
Brian McKenna has written a blog post about how to configure an Android Studio project to use an Eta library.
There is https://github.com/neurocyte/android-haskell-activity demonstrating Haskell code running.
I once came across the same Reddit thread, but it was old, and comments were closed. I sent a message to the OP, but am not sure whether it reached the recipient. My suggestion here (may work for older Androids where native activities were not possible).
I (developed in Haskell some time ago, but currently switched to Smalltalk) am currently developing a port of Squeak VM to Android. The way I am doing this is similar to what might be dealt with in a haskell-on-android project: a lump of C code which needs to be called from Java part of the application (basically all that can be done in Android is to handle various events; an application cannot poll for events itself and does not have any event loop). In my case the code is generated by the Squeak VM building tools, in the case of haskell on android this will be output from GHC of JHC or whatever front end used. This repo may be worth looking at:
http://gitorious.org/~golubovsky/cogvm/dmg-blessed/trees/master/platforms/android/project
Under "src" there is the Java code which provides for user events interception and sending them to the native code (see the CogView class). The C code of the VM itself is not completely there (see squeakvm.org, the Cog branch for that), but one may get the idea. One also might look under http://gitorious.org/~golubovsky/cogvm/dmg-blessed/trees/master/platforms/android/vm which is the C frontend to the interpreter (including user events handling, some timekeeping, etc.)
Hope this helps.
Dmitry
There is https://github.com/conscell/hugs-android a port of HUGS Haskell interpreter to Android.
I think the general answer should come from source->source transformations, since loading specially compiled shared objects seems to be a bit of a kludge (involving ghc->c and a c->java step in the answers above). This question thus falls under the heading of Haskell on the JVM, which has been tried (with one step as a Java intermediate representation) and discussed at length. You could use frege if the libraries you need compile there. The only remaining steps would be the beginnings of the Android framework API translated into IO() actions and maybe a wrapper for building the manifest xml and apk.
I'm doing some initial research on smart phone development, and I noticed that Android and Windows Mobile both support c++ for application development. I was curious if anyone had any experience trying to manage shared files between both Android and Windows Mobile, and to what extent that code can be shared? e.g. no user interface can be shared, but web service and business logic classes can be shared, etc.
I can't speak to the WinMo side of things, but on the Android side you should really really really avoid using native code for anything except performance-critical processing algorithms. JNI/NDK stuff does not play nicely with the normal Dalvik lifecycle and can be a source of all sorts of ugly unpleasant bugs and memory leaks. From what I understand there also aren't on-board NDK libraries for more complex high-level functionality like HTTP (just more basic/performance-oriented libs like libz and OpenGL), so you'd probably have to compile that stuff and ship it with the app as well. I would definitely not recommend coding your web service classes in C++, even if it's technically possible; it'll be less buggy and nicer to write C#/Java and you should be able to make mostly the same architectural decisions for consistency.
That said, if you have a performance-critical bit of image processing code or the like, it actually can be fairly straightforward to get that working across Android to other platforms (I've seen it done quite well with some image-processing C code used in an iPhone app and then used via the NDK in an Android app).
Check the documentation on the NDK for details on what it can (and can't) do, and see similar SO threads like this one.