Im writing my entire Android project in NDK C/C++, and I now want to open some jpg files.
Ive read a lot people suggesting compiling libjpeg or libjpeg-turbo for use with NDK, but others suggesting libjpeg is already in with android is this true?
I'd rather use an existing lib but dont want to rely on it if some units its not there.
I use libjpeg-turbo, statically linked with my other libs, it works fine. I don't think libjpeg is already installed on Android.
Even if libjpeg already exists within android, it's not a public API, so therefore whatever gain you get by not having to bundle it, might come back and bite you later. I'd say it's not worth it - bundling your own copy of libjpeg (or similar) makes sure you don't rely on platform internals.
If applicable, you could use e.g. some of the public java APIs (android.graphics.BitmapFactory etc, which in the end calls the internal bundled libjpeg or whatever) via JNI to decode your images - then you don't have to ship the jpeg library yourself, but have to do a bit more JNI function calls. (There might be a small performance overhead compared to calling libjpeg directly, but not significant unless you're loading huge amounts of images.) If you're interested, I can share example code for this (it's about 50 lines).
Solution:
Thanks guys for the help, I was hoping libjpeg was accessible to my development but as pointed out is in Android though not public through the NDK.
So I spent sometime reading the spec for jpg and decided on writing a C decompresser from scratch until I fell upon jpgd by Rich Geldreich, and although C++ its single file implementation of jpeg decompresser in the public domain which Ive now used without any issues on Android.
He also has an accompanying jpge (encodeder) although surplus to my requirements for this project well worth noting.
My NO-JAVA application continues.
Solution:
C++ jpg Decompressor Android NDK
Related
I'm developing an Android application which contains native code.
The native code is compiled in a .so file that has important algorithms inside.
I'm really worrying about the possibility that my .so file can be edited or modified and then re-build (re-pack). Like apks they can be modified and repacked to create a new one
I have several questions here:
1) Is there any way to edit/modify .so files and re-build?
2) If there are, how do people do that?
3) How to prevent .so files from being edited then re-built?
The short answer is that anything that a computer can read and understand, it can also modify. There is no bullet-proof signature mechanism in Android for Java or native code. Still, the so files are generally considered much less vulnerable than the Java code, even with obfuscation turned on.
Reverse engineering a shared library is hard but possible. Disassembly, change, and assembly back is not hard if one knows what to change.
There are many ways to strengthen protection of your C++ code against reverse engineering, but none will hold against a determined and well-funded attack. So, if the stakes are very high, consider running the important part of your algorithm on your server, and prey for its security.
I am developing an application for android/iOS/windows using c++ code for the core logic. The application uses the free fuzzy logic library and it works perfectly for windows mobile, iOS and on my local Ubuntu machine, but it doesn't quite work under android.
The application reads a .fcl file from the sd card and then parses it using the free fuzzy logic library parser. The problem is, that the parser gets stuck at random stages of parsing.
Some notes to my project settings:
I enabled the Android read/write permissions for the sdcard in the manifest.xml.
The code I am trying to run is the basic example from the free fuzzy logic library website.
I am using the stlport_static library for stl support and the -frtti compiler flag.
My question is: Am I missing something android specific, like file encoding or some permissions I didn't set?
Some notes I thought about:
File compression should not be an issues, because, to my knowledge, files on the SD card are not compressed and I can parse the file partially.
Using other fuzzy logic libraries is out of the option, because I can't use GPL licenced libraries. The only other library I found didn't hat a manual / how to and couldn't parse the fcl standard.
The free fuzzy logic library uses a lot of wchar_t's whitch could be an issue.
Thank you for your time and hopefully for some help ;)
Ok after plowing through some android manuals and some Google abuse I found the problem. Currently Android doesn't support the wchar_t type. Well you can use it, but the results will not be the same as on any other operating system.
By changing all the wchar_t and wstring types in the free fuzzy logic library to their corresponding char and string types I was able to make the parser work. Well sort of, there are still some sleight inconsistencies, but nothing i can't handle ;).
Conclusion: Don't use wide characters in android c++ Programs.
Thank you for your time & help
I have a lot of data (text format) to send from a device. It obviously means that I should compress it. But my question is whether there are any ways of doing it other than by zip algorithm (like this). The reason I am asking this question is over here - for a text file i.e. 7-zip is twice (!) better than zip. Which is a significant gain. And maybe there are even better algorithms.
So are there any effective ways of data compression (better than zip) available for Android?
You would need to compile another library into your code, since I doubt that compression algorithms other than zlib are available as part of the standard libraries on the Android.
The 7-zip algorithm you refer to is actually called LZMA, which you can get in library form in the LZMA SDK. The source code is available in Java as well as C. If you can link C code into your application, that would be preferable for speed.
Since there's no such thing as a free lunch, the speed is important. LZMA will require much more memory and much more execution time to achieve the improved compression. You should experiment with LZMA and zlib on your data to see where you would like the tradeoff to fall between execution time and compression, both to choose a package and to pick compression levels within a package.
If you find that you'd like to go the other way, to less compression and even higher speed than zlib, you can look at lz4.
Your question is too general.
You can use any library, as long as it is in Java or C/C++ (via the NDK). If you don't want to use external libraries, you have to stick to what's in the SDK. Depending on how you are sending the data, there might be standard ways to do this. For example, HTTP uses gzip and has the necessary headers already defined.
In short, test different things with your expected data format and size, find the best one and integrate it in your app.
I have a very basic question regarding Android and ffmpeg. I obtained ffmpeg from http://bambuser.com/opensource and was able to compile it for ARM.
The results are the binaries (ffmpeg) as well as several libsomething.so files.
My question is: Is this enough to decode videos? How do I actually use ffmpeg then?
To load the library I have:
static {
System.load("/data/data/com.package/lib/libavcodec.so");
}
It loads fine. But what then?
More explanation: I saw other projects where people had their ffmpeg source in a JNI directory in the project. They also created some Android.mk files and some C code along with it. Would I need this as well? Why would I create the .so files first and then copy the ffmpeg source code again?
I know the NDK and how it should work but I've never seen an example of how one would actually call ffmpeg functions using it, because people seem to be hiding their implementations (which is sort of understandable) but not even giving useful pointers or examples.
Let's just say I wanted to decode a video file. Which kind of native methods would I need to implement? How do I run the project? Which data types need to be passed? etc. There are certainly a few people here who have at least done that, I know this from searching for hours and hours.
For your first question;
Just building is not enough for the proper use of the ffmpeg libraries. You should also wrap those so files in the right order because these so files NEED other libraries in the link time. You can display header information of the so file, by using.
objdump -x libavcodec.so | grep NEEDED
So you need to wrap these so files through Android.mk. You may check this link.
The second one;
You only need the header files from the ffmpeg project. The implementation will linked from the so libraries. Thats perhaps because, developers didn't bother to filter header files.
And the last one;
your thoughts seems right for the time being, most of the current developers are struggling to use ffmpeg but they lack of documentation and sample codes.
I am writing an Android application that would both store data and communicate with a server using protocol buffers. However, the stock implementation of protocol buffers compiled with the LITE flag (in both the JAR library and the generated .java files) has an overhead of ~30 KB, where the program itself is only ~30 KB. In other words, protocol buffers doubled the program size.
Searching online, I found a reference to an Android specific implementation. Unfortunately, there seems to be no documentation for it, and the code generated from the standard .proto file is incompatible with it. Has anyone used it? How do I generate code from a .proto file for this implementation? Are there any other lightweight alternatives?
I know it's not a direct answer to your question, but an extra 30kb doesn't sound that bad to me. Even on EDGE that'll only take an extra 1 to 2 seconds to download. And memory is tight on android, but not THAT tight -- 30 kb is only about 1/10th of one percent of the available application memory space.
Are there any other lightweight alternatives?
I'm taking this to mean "to using protocol buffers", rather than "for using protocol buffers with an Android application". I apologise if you are already commited to protocol buffers.
This site is about "comparing serialization performance and other aspects of serialization libraries on the JVM". You'll find many alternatives listed there.
While there is no mention of the memory footprint of the different implementations at the moment I am sure it is a metric which the people on the wiki would be interested in.
Just to revive this archaic thread for anyone seeing it, the answer is to use Square's Wire library (https://github.com/square/wire)
As they mention themselves:
Wire messages declare public final fields instead of the usual getter methods. This cuts down on both code generated and code executed. Less code is particularly beneficial for Android programs.
They also internally build using the Lite runtime I believe.
And of course Proguard, the new Android 2.0 minify tools, [other generic answers], etc etc.
Use ProGuard[1] on your project. It will reduce the size of jars included in APK file.
[1] http://developer.android.com/guide/developing/tools/proguard.html