Develop Reference

How to use .so lib in an Android application

I am working on my master thesis, where I am looking at the security for an IoT device, which is controlled by an android application. At this point, I have reverse engineered the application and looked through the code that came out of it. An interesting discovery is that it is using a .so lib to communicate with the IoT device. So, I would like to build a POC android application where I use this same .so lib.
Now, my question is: how do I do this correctly?
From what I have understood so far, I need to put the .so lib into the structure:
app/jniLib/armeabi-v7a/*.so
Then I need to load the library in java with:
static {
System.loadLibrary("something_lib");
}
Now if I wish to call a function I should do this by using the "native" keyword:
But, as shown in the image above, the function is not being found. So, I properly miss something or am doing something completely wrong.
I've looked at a project on GitHub (https://github.com/SandroMachado/openalpr-android), which is also using .so lib. But I'm having the same experience when I open this project.
I have also had a look at the Android NDK guides (https://developer.android.com/ndk/guides/prebuilts.html), but sadly it did not make me a lot smarter. Here it says something about an Android.mk file, is this still something I need in my situation? If so, I would love if something has a link to a page or can explain to me the missing gaps I have in my knowledge about how to do this.
A simple example/guide for how to use a .so file in a project would be the ultimate solution for me at this point.

Maybe this thread help you:
How to include *.so library in Android Studio?
Looks like you should integrate your *.so files into src/main/jniLib/armeabi-v7a/*.so rather than app/jniLib/armeabi-a7/*.so. Verify that your arm-directory is named armeabi-v7a and not armeabi-a7.

Generating vulkan_wrapper.h/cpp

I'm trying to write a barebones Vulkan app on Android. I'm finding that most of Google's example apps rely on vulkan_wrapper.h and vulkan_wrapper.cpp. Google's Vulkan documentation also says to use them.
I would love to use them but they are part of the example projects' code, not the SDK, and the header says that they are generated. So how is a developer supposed to generate them for their project? I have copied them from a sample app for the time being but am curious what the best practice is for generating them and keeping them up-to-date.

I'm not sure how they're generated, but you could just copy them into your project. There shouldn't be much need to regenerate them, since they only contain the core and WSI extension entrypoints normally provided by libvulkan.so; even if you regenerate it, it won't contain other extensions that might have been added to vulkan.h.
The only reason to use these is if you want to avoid linking against libvulkan.so directly, which only matters if you want your app to load and run on devices that don't have it (Marshmallow and older).

Not sure How they get generated but you can do something like that if you want it to. Vulkan layers come with the scripts and the xml file, you can modify the script to your requirements. We are already doing that in our projects. The script can be found here.
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/tree/master/scripts

Android Source: What is building exactly and is it necessary to test small changes?

For a project, I am changing certain ContentProvider-files in the Application Framework Layer of the Android System. As I am trying different things, I was wondering if it is necessary to build the Android Source for every change I make, or if there is a way to somehow emulate the system without the build?
I am not entirely sure what "building" means, as I cannot find a proper definition including Android as a context. I assume it is some kind of compiling?
Converting the source code into an executable program? In that case I do not think there is another way, is there?
But do I understand building correct in the first place? In that case, I would believe there is no other way than building the system every time and then see how it works out.
So I might have the solution right here, but I was hoping someone could assure me that it is right or maybe tell me why it is not?!
Any help is very much appreciated!

Building in this context means that all Android source files are re-compiled by the java compiler and a massive .jar file is produced. This is the Android.jar file that we see in the library dependencies of an Android application project.
Unfortunately, the short answer is that there is no way out for you except to re-compile the entire blob of the Android framework files each time you make a change. What I can advise you is to plan all your changes beforehand so you don't end up wasting a lot of time.

Manage code/build for Android app stores (Google/Amazon/etc)?

I have an Android app that's downloaded primarily from Android Market (now, Google Play). We made a few tweaks to the source and also submitted to the Amazon App Store to see what sort of traction it gets. I'm now looking for a sustainable way to develop from a common code base and yet build so that I can submit to either/both.
Amazon's store has some restrictions about available APIs, and hence I'd like to conditionally remove/modify features from that version. Since Java doesn't support traditional conditional compilation, and conditionally including files in Eclipse doesn't seem trivial (is it even possible?), I wanted to ask what others are doing to solve this.
Admittedly, I'm no Eclipse/Java expert so feel free to school me.
What I'm looking for in a solution:
Building/debugging using Eclipse.
Static code files, with environment/settings toggles to control what to build.
No duplicate code or conditional logic in code to pick code flow at runtime
Is this something you've solved for Android apps specifically, or for other Java/Eclipse based projects? Suggestions for where to begin?

It's quite easy to do in the newest versions of ADT (version 17), though I do find it makes compilation a bit longer:
Create a new Android project (proj-A)
Go to Project->Properties, select Android, and check "Is Library"
Move all your common code to proj-A, import all the necessary libraries
Create a new Android project for Google Play (proj-B)
Go to Project->Properties, select Android, and add Proj-A to the Library
Repeat #4&5 for the Amazon version
If you have some variables that should be set differently for each sub project (i.e. boolean GOOGLE_PLAY_VERSION to enable Google Play specific functions), you have to create another project to contain these values since you can't have projects that reference one-another in a circular fashion. You can solve this by adding the following steps:
Pull all of your sub-project specific variables into one or more Classes that just serves as container(s) for these variables
Create a "dummy" Java project (dummy)
Config proj-A to add a new Source link to the bin directory of dummy
Add the config Classes in each sub-project with project-specific changes
Profits!
Note that the variables in dummy should not be set as final, otherwise it will override sub-project's setting.
This may seem like quite a bit of up-front work, but has worked quite well for me as far as version control goes.
Edit:
Now with Google's move to Android Studio & Gradle, it may be better to move to that if you are starting a new project if you want to support multiple APKs, see Android dev site's Building Your Project with Gradle#Work with build variants. It definitely doesn't hurt to evaluate that option before deciding.

Unfortunately, it's sort of a convention in Android to change flow at runtime based on what would be in C/C++-land conditional compilation.
Our app has to maintain different behavior for different API levels, so we've created some application-level constants that are initialized statically based on API-level information available to us, and used throughout the code. This is the way that Google does things in their examples (for example, see the ActionBarCompat compatibility library, and in particular the factory method used here).
You could create an interface CustomBuild, and implement it in AmazonBuild and GooglePlayBuild, then use a static getBuild() method to switch functionality as necessary:
if(getBuild().shouldEnableFeatureX()){
doStuff();
} else {
doDifferentStuff();
}
Then all you've got to worry about switching between builds is a line or two of code in the factory along with maintaining which things you want enabled in which versions. Or you could include a different version of a static class CustomBuild for each build.
I'm going to second the suggestion of others above re: switching to something like Maven for building; it should make your life much easier once you have it set up.
I'm also going to say you should make the core of the app a library as suggested above, and have two different modules (one for amazon, one for play store) that depend on the library but each only contain the one custom factory file (or just a static class for each type of build that contains the same "should I do this thing?" methods... once you have the infrastructure it's just a matter of preference).

I haven't actually tried this yet, but it's something I've thought about.
How about using Eclipse's ability to link to files from a directory outside your workspace?
Start with one Eclipse project: for the sake of argument, say it's the Google Play version.
Now build a second project, beginning with asking Eclipse to link (not copy) the source files from your first project.
To develop the second project, add classes that subclass ones from the original project to realize your modifications. For resources, you can use some combination of includes, attribute overrides, and selectors.
Where it's not possible to subclass or extend, then obviously you'll have to just copy the original source file and hack on it. If you're really OCD about it, you can probably just maintain a patch set rather than a whole redundant set of files.
What do you think, will it work?

You may create manually two projects in Eclipse pointing to the same source folders but with different inclusion/exclusion filters and different target directories.
Then two Ant targets using properties to switch excluded files from javac fileset are enough to generate corresponding jar files.
The aim is to get a clean application for each target, without any code from the other one.
With features listed as pluggable behaviors in a property file or XML configuration, your runtime will adapt itself with the addition of menu entries.

cvCreateVideoWriter (OpenCV 2.2 + FFMPEG)

I'm working with OpenCV 2.2 for Android under Windows, and faced a problem when using cvCreateVideoWriter. It always returns NULL. I'm guessing it has something to do with library FFMPEG not being properly built. The thing is that I followed instructions in http://opencv.willowgarage.com/wiki/Android2.2, and since FFMPEG is included as a 3rd party library (at least I can see the source withing the whole OpenCV package) I thought I didn't have to do anything extra to get this library installed. I might be wrong. How do I check if the library was correctly built (or built at all)? Do I need to make any changes to the default make files?
Any help is much appreciated.
Thanks!

There are 2 important things to consider when using cvCreateVideoWriter():
Your application needs rights to create files and be able to write on them. Make sure you have setup the necessary directory permissions for it to do so.
The 2nd argument of the function is the code of codec used to compress the frames. For For instance, CV_FOURCC('P','I','M','1') is MPEG-1 codec and CV_FOURCC('M','J','P','G') defines motion-jpeg.
A typical call may look like this:
CvVideoWriter *writer = cvCreateVideoWriter("video.avi", CV_FOURCC('M','J','P','G'), fps, size, 0);
if (!write)
{
// handle error
}
I suggest calling cvCreateVideoWriter with different codecs. It may be that your platform doesn't support the one you are using right now.
I don't know if the default build for Android enables the flag HAVE_FFMPEG, but you need to have ffmpeg installed and it's best to make sure this flag is enable when compiling OpenCV.