Android project with a native component. I'm using a third party library where I suspect there's an bug with uninitialized or unreset variable. The same sequence of calls (should be equivalent according to the interface definition) yields different results.
I've got the sources to the library, but I don't want to dig deep in them (it's really big and convoluted). Is there a way to leverage something like GDB to compare two runs of a piece of code - see if the variable state diverges at any point? It should not - the code is completely in-memory, no I/O or randomness there.
Related
I'm new to Android NDK, and I was reading these tips on the Android Developer site. It recommends using JNI_OnLoad to register your native methods, but doesn't give much detail on how to do that.
Searching Google's NDK sample repo on GitHub only turned up one usage of JNI_OnLoad, and it doesn't call RegisterNatives. Searching the web didn't turn up much on how to do this either.
I feel like I'm missing something. This is supposed to be the correct way to do it, according to Google, but their own examples use the "discovery" method naming approach instead.
Is this perhaps an old way of doing it, that's not really done anymore?
RegisterNatives is fully supported on Android, and the proper way to do it is from JNI_OnLoad, which also works well and is shown prominently in NDK documentation. There are few reasons to use RegisterNatives vs. the usual automatic resolution of native methods through name matching (always use javah to get correct names).
When you have many of native methods, you may not want to have a huge exported function table in your shared library.
Using automatic matching makes reverse engineering and hacking your shared library easier.
You can build custom logic to match native methods at runtime.
#CriticalNative methods must be registered with RegisterNatives instead of relying on dynamic JNI linking.
None of these reasons apply to how-to samples and introductory tutorials.
I was wondering - how 'safe' are the functions provided by android libraries when doing development of other native libraries on android?
Are there things like Microsoft's strsafe.h or bstring? Or can those be ported over?
There are usually safe variants of unsafe functions you can use to ensure any manipulation problems are generally detected and dealt with before introducing difficult to detect bugs only noticed later on in execution. If I understand your question correctly, you may want to look at things like snprintf in place of printf, strncat instead of strcat, and using variants of malloc when creating character arrays that follow the 'succeed or die' convention.
I find these references helpful when coding in C for Android (I know the native library is lacking a bit).
http://www.cplusplus.com/reference/clibrary/cstring/
http://en.wikipedia.org/wiki/C_string_handling#Overview_of_functions
Using variants that require additional information, such as max buffer size or trigger easy to spot errors on failure is generally helpful to avoid subtle bugs that can be a hassle later on.
I've been doing a fair amount of research, and have even experimented some with the NDK for Android (not so much the SDK). What I haven't been able to really find though is a clear and concise definition for what the NDK cannot do (besides lack of exception handling and rtti).
I've been mapping out some code for a game and a game engine for Android (Written entirely in the NDK) but it seems to not be as supported as many would like it to be. Not only that, but I'd like to be able to give my game a sexy U.I. without having to write everything from scratch in OpenGL.
While I'm sure it's easier in Java, I'd like to know if the NDK's front end/U.I. components are getting to a point to where they'd even be comparable with Java in terms of Touchscreen IO , Sound, and Graphical Interfaces. Worst case scenario I can write the U.I. in Java and just call native methods from that, but I'd like to be able to do more if possible.
Thanks.
Edit
If C++ is even somewhat on par with Java's U.I. feature set, it would be cool to know which of the two gives more control and customization. For example, while the Java implementation may be easier to use, does it give the programmer a lot of options to fine tune a "look" which resembles something specific?
Official NDK can do exceptions and rtti just fine. Read the "docs/CPLUSPLUS-SUPPORT.html" file distributed with Android NDK.
In C++ only thing you can not do is implement Java interface, inherit Java class and define new Java class. Otherwise - you can do everthing Java can. Only problem with that will be that a lot of things (like accessing Java object members, or calling Java functions) will require usage of JNI and that code will look really ugly. So if you need for UI creating/inheritance of Java classes, then you can code everything in C++.
I suggest to use JNI only for performance critical code. Mixing code - Java for UI, mathematical calculations in C/C++ is really easy.
Or if you code game by using OpenGL ES - that's also fine.
What is happening under the hood? somehow this is passed down to the OS, and someshow the OS will find the right activity / activities, and launch it? Is there a service / lib running in Android handling this? I am trying to modified the OS to override the logic of startActivity across the board, is this possible?
Thanks.
I would take a look at the Android source! Whenever I'm developing and I run into an issue I read through the source to discover what is happening under the hood; it's quite interesting! It's an insight into what's actually going on, and also very good guidelines for documentation and code formatting!
http://source.android.com/source/downloading.html
A good starting point might be ActivityManagerService
Basically, when an app is first launched, startProcessLocked() in ActivityManagerService creates a new ProcessRecord (if necessary) and then calls Process.start(), which in turns builds the arguments for zygote and sends to zygote's socket using zygoteSendArgsAndGetResult(). Of course there's more to it than that, for example if an app shares a uid, is isolated, etc. But that gives you the basic process.
Looking over the source is indeed a good way to understand what's going on. However, unless you're planning on modifying it, don't bother downloading AOSP, just use GrepCode. Easier to browse, search and everything is hyperlinked so it's easy to follow through to classes, find usages, derived methods, etc. If you download AOSP, you'll be stuck with grep, ack-grep if you're lucky and a text editor. Also, you'll only have the one version you picked to checkout. GrepCode has the code for almost every version since 1.5.
The linked text above will take you to the relevant source at GrepCode. Try it out! The only downside is that GrepCode doesn't include the native C++ layer.
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?