I posted this question previously on G+ Android community, but no answer so far.
It's about downloading and loading native libraries.
I've been reading around and what I learned it that, it is in theory possible to download a ".so" file, and load it from using System.load method.
But I also read the following here (https://groups.google.com/forum/#!topic/android-ndk/0uY4qgam1Ws) : "Also you should not be able to load an .so off the SDCARD on an ARM system by normal means, as ARM supports non-executable pages and android's implementation of mmap() refuses to map executable pages backed by a noexec file system."
It is a bit confusing for me to fair (a lot confusing actually).
So here is my question : is it or is it not possible, on a production device, to download a library, stick it somewhere on the phone, and load it then use it with JNI.
And if so, are we sure that it will still work in the future with new versions of Android?
Like, what is the official recommandation of Google about this?
Yes, this works on production devices. But it doesn't work on all devices if you put it in /sdcard, you should use the app private/internal folders (that correspond to /data/data/com.example.app/something) for this. You might need to do the equivalent of chmod +x on the file after creating/downloading it though.
I'm not sure if there's any official Google recommendations about it though, but the post you linked pretty clearly indicates that this is intended to work and there's no plans to break it.
Related
I've developed a SQLite wrapper for React Native using C++. The easiest way to get it working was to include the SQLite amalgamation in the sources. This however increases the bundle size significantly. So I want to give the users the option to use the phone's embedded SQLite version.
The iOS version is working (I exclude the sources if an environment flag is present). Android seems a lot more complicated though. Most of the answers I find on google recommend using the amalgamation path. It seems however it is possible to use the phone's SQLite version (it comes by default with the NDK).
I'm currently compiling the amalgamation via CMake.
I'm an Android noobie, would someone explain it like I'm 5 how can I link/access the SQLite headers from my NDK C++ code? Maybe I should just leave the sqlite.h header file and it will link with the phone's version?
EDIT 1: It seems leaving the header file only, does not work. I've also ran into this Hacker News thread. Some of the comments seem to suggest it is not really possible to access things like curl/sqlite/etc from the NDK code. Any thoughts?
Thanks a lot!
Edit 2: I found a link that might work https://blog.katastros.com/a?ID=00200-fd6cd935-b779-4f44-9b4c-efad582167e1
After much fumbling around I've come to the conclusion there is no way to achieve linking the phones sqlite via c++. It is also probably best so, old android versions have outdated versions, vendors also modify the running sqlite versions and they are full of old bugs and broken stuff.
I am using Ubuntu 19.04 as OS, and I developed a small application using Qt5 and QML.
I have been researching a way to transfer what I built so far into my Android phone Note10 but also on additional Android devices a little bit older.
I found really a lot of tutorials on line (YouTube) but every tutorial has a different way to do that. I have never done it before and am looking for a super basic standard procedure.
I went on the official documentation but the link goes nowhere.
How can I easily and using a step-by-step procedure deploy a basic application on my Android given the OS I am using and the fact that I programmed it in Qt5 and QML?
Things to note: In my application I implemented the smtp library that is possible to find [here]
(https://github.com/bluetiger9/SmtpClient-for-Qt) and wanted to understand if there are any other things I should do since I used that external package.
I simply copied and pasted the .h and .cpp files inside my Sources and Headers folder together with the other files of the application.
Also I found this very old post and was wondering
if the procedure is still the same or if there is an additional step-by-step to follow.
Thank you very much for pointing in the right direction on this matter
I am working on a device driver which android apps use. Whenever I make a small modification to the driver and recompile the modified drivers, it seems like the app is not using the modified driver but still use=ing the previous version. I am sure about this because the modifications made includes print statement which doesn't showup when the app runs.
However, once I delete the driver and rebuild it or restart the system then it seems to work fine.
The problem with doing this is that it is time consuming, because I have to be sure that the app is using the latest driver.
So my question is that whether android cache the libraries? If so are there any simple hacks to prevent it from doing so?
EDIT:
As a matter of fact I can delete my device driver and the app which uses it still runs without reporting a problem about missing driver !!!!!!!!!!!!!!!!!
Yes, android apks do cache the libraries. If you have installed xyz.apk on your board, then there will be folder created called com.xyz, this folder will contain a cache folder which will cache the libraries, so newly modified driver is not picked up by the apk.
To bypass this effect you can
Manually delete the cache folder from the above mentioned location.
Uninstall the apk and re-install it agian
Reboot the board
HTTP caching is both important, as it reduces bandwidth use and improves performance, and complex, as the rules are far from simple. In my experience, most Java and Android applications either don’t do HTTP caching, or they roll their own and up doing it wrong or in way too complicated a fashion. In other words, they create a non-standard, one off, unmaintainable solution. And IMHO, that’s no solution at all.
If you find yourself using HttpClient, you can use HttpClient-Cache, which is an easy drop in for Java. See my previous post about HttpClient-Cache for Android. But if you’re using HttpUrlConnection (aka java.net.URL.openConnection()), there’s no good solution for regular Java or Android. Well, in Android 4.0 and later, you can use HttpResponseCache, but with only a small percentage of Android devices using 4.0 or later, that’s not a terribly good solution. If you use Android 4.0+’s HttpResponseCache as recommended by Google, then all previous Android versions end up with no HTTP response caching – this causes excess load on your servers, slower performance for the app, and unnecessary bandwidth use.
To fix this problem, I grabbed all the code from AOSP that implements Android 4.0′s HttpResponseCache and made it a separate library. This library is easy to use, works on Java 1.5+, all versions of Android, and is licensed under APLv2 (just like everything else in AOSP). Really, there’s no reason not to use it! You can even use in Java server applications, such as those that use Spring.
I was using opencv for some time for programming in Android, and I now see that the Gimp library is much stronger. Where can I find a starting point to learn Gimp?
I also want to know the basic concepts behind of Gimp plugins. In the past, I used C APIs in opencv. How could I write the code for android?
Also, what packages do I need to install in windows to start using Gimp?
ALthough GIMP dows have some standalone libraries that perform some image manipulation, most image manipulation is done either by GIMP's core program or through GIMP's plug-ins. Both approaches need to have the entire program installed and running (though not necessarily usin a display).
I know nothing on Andorid progrmaing, and don't knwo how can one install ordinary native code in C and call it from Android apps - if you are very familiar with it, you might have a chance in your attempt.
However GIMP itself relies on a extensive ecosystem of libraries, including, but not limited to, glib, gtk+, cairo, pango, gegl - and each of these in turn might have other pre-requisites. Since Windows does not have a working package manager to authomatically install libraries and header files of these various libraries, working with these natively on Windows, though the code of each of them is multiplatform and can run on Windows and other OSses,is very hard. So hard that hthe people who build GIMP for Windows themselves do so in a Linux environment, from where they cros-compile GIMP for Windows.
Making all of these libraries work on an Android is probably not hard if you are using the GNU ecosystem around the Android's Linux kernel , and not just the bare Android environment (I don't know enough about android to even know if that is possible).
All in all: it will be though for you, and demand a whole lot of research.
One of GIMP's libraries, the GEGL (Generic Graphics Library) has a lot less prerequistes, and can be used as an ordinary library. I think you can probably build it with just glib and Babl as prerequisites. This is the library that will replace current's GIMP core, and reimplement the operations of most existing plug-ins -- so it might be enough for you.
If you can get GEGL running and usable from an Android system share that with the World --it would be , in itelsef, a project worth of a Google Summer of Code project. (And still would be about an order of magnitude easier than getting GIMP code in there to be used as a library from other applications).
Finally -- if you want just a couple of GIMP's effects, if the effect is implemented as a Plug-in in GIMP, the plug-ins' code is quite straightforward. So, while it would be hard to get the whole GIMP environment inside Android, copying the functions that actually perform the pixel manipulation from GIMP's source tree and converting them to work in a java method inside your app would not be hard. Just remember to comply with the license in this case: GIMP's plugins code is under GPLv3. (the GEGL library is only LGPL)
In short: no, you can't use GIMP's "libraries" as native code from an Android app -if you can use OpenCV, you have a good chance of being able to use GEGL instead. Only orting the algorithms of certain plugins to manipulate pixels in your app would be easier.
However -- if your application would allow delegating Image Processing to an internet based server, setting up an HTTP application to receive a image, use GIMP to process it, and stream it back would be a simple thing to do.
(So, you could not apply effects in real time, but would allow one to, for example, take a photo, select a series of effects from menus, and send it to the server for processing)
GIMP uses quite a bit of memory when loading brushes. If you drop all of the useless plug-ins, and build it from source. You may be able to get it working but you will have to build ALL of the linked libraries directly into the executable.
In other words; build linked libraries directly into the code as a static build. In this manner things may function properly unless one of those linked libraries call another linked library.
Getting the libraries themselves to work on the OS may provide additional programs opportunities to use them. Additionally, GTK+ (GIMP Tool Kit), GIMP's interface is also rather bloated and ugly.
If all else fails, you'll simply have to settle for a smaller program with the features you're looking for on the fly ( Levels, Curves, the clone tool, dodge and burn, etc. ) Layers are also nice, but editing a a large megapixel image begins to eat up memory rather quickly and most android device don't have a swap partition.
I am newer to android development. I have a couple apps I've made with appinventor. I would like to be able to take a completed and packaged .apk that is saved on my computer that was made with appinventor and open to edit it in eclipse. Mainly I want to see how a working app Ive made is actually written. This is for my own educational purposes only, no pirating or other illegal uses.
generally it is not possible to convert an App Inventor project into Java. However there are projects which have this goal, see the App Inventor-Java translation project and the Java Bridge project.
Check the android-apktool. I have no experience with the tool and as I see it will not show you the sources but it seems to be the best way to 'unpack' apk files.
I doubt this is possible, how are you going to bring the dex code back to your java code, even then, AppInventor makes for horrible APKs, two apps that do the exact same thing will differ greatly in size if made with the SDK vs AppInventor.
You should just read a couple of books, or search for information online, instead of trying to unpack an APK.
It's absolutely possible using dex2jar which involves a little time to set up and run but it give you a .jar that you can open with a java decompiler. As for getting the source files into eclipse, there are probably some decompilers that do this but probably cost money. You can use the one listed to copy/paste the code out but it will not provide you with an eclipse project.