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.
Related
I'm building an app with android studio with another developer. Is there any way in which I can make it so that both my partner and I can work on the project at the same time on different computers (both Windows computers)? I know there is a similar question, but I am looking for a more detailed explanation on how to do it.
My suggestion: Use Version Control preferably git.
This will help both of you to develop Apps without any problems of copying & pasting and manually making changes in all files one-by-one.
Note: Want to use git but do not want to open source your code (since Github allows creating private repository but with some Payment), then use Bitbucket, you can create private repositories for FREE!
EDIT: Github now provides unlimited private repositories.
Hope it helps!
Take a look at git. I will help you and your partner to work on the same project on a different computer (Windows, Mac, Linux...).
https://www.atlassian.com/git/tutorials/comparing-workflows
As others have indicated, you should use a version control system like git for this. This will give you the following features (among others):
The ability to share code between people
Essentially keeps a backup of your code on an external server
Keeps a history of revisions to files (so you can "back out" changes if you need) as well as differences between your local file and the version on the server
Allows you to merge changes between you and people working with you
How you do this will depend on which version control system you use, but some version control providers will allow you to also set up what's known as "Continuous Integration" - basically, if you or your partner check code in, it'll immediately start a build. If this is available to you, I strongly recommend using it. The advantage of that is that it'll give you quick feedback if you did something that'll prevent it from building for the other person (e.g. if you forgot to check in a file or something). This'll prevent a lot of frustration and wasted time. (This happens a lot more often than you'd think; you don't want the other person to have to spend half an hour trying to get the app to build again when they download your code only to find out that you forgot to check in a file).
I also strongly recommend integrating your stuff with each other as often as possible as well as practicing regular "re-baselines" (i.e. downloading each others' stuff and merging it with what you have locally). The longer you wait to integrate your stuff with each other the more complicated it'll become, and waiting too long greatly increases the risk of introducing bugs when merging or forcing unnecessary rework.
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.
An Android application that I am interested in (OpenSudoku) has become unmaintained by the original author, who last updated the application just under a year ago, in addition they have rejects offers of help from others to contribute directly to the hosted SVN repository.
I am interested enough in the project to seriously consider forking it (I am already familar with many arguments for and against forking in general), but I do have a couple of questions related to best practice with forking Android applications, specifically:
I understand that I will have to change the package name/namespace, is there an easy method I can use to do this (without breaking the Eclipse project files and associated references)?
Is there a way to help users that may want to migrate to the new application, recover settings/data from the original application? (My understanding is that the permissions model that Android enforces would make this impossible)?
Are there any other issues that I should be aware of that comes with forking an Android application that I would need to plan for?
AndroidManifest.xml, various build system files, layouts that use your own views, each Java source file, and the directory tree. That's what you have to change. I use vim -p glob glob glob for changes like this, and mv, which is easy enough.
Not unless the old application cooperates, which it likely doesn't. Perhaps your fork could detect an OpenSudoku install and prompt the user to install, off-market, an 'update' for it that just repackages its preferences for your consumption. I don't know if that works, updating a Market app with a non-market APK. Although, you said "settings/data". If 'data' includes e.g. sets of puzzles on the sdcard, yes, you can load that kind of data without any trouble -- FAT32 offers no security.
Sorry for my terminology, but here is how it goes.
I added GSON package JAR to my Android application and all was well until my app started to fail on some HTC devices - here is summary:
http://code.google.com/p/google-gson/issues/detail?id=255
So, in order to fix that - I had to get GSON sources and embed those into my app while renaming all namespaces. Time consuming and hard to upgrade now.
So, anyway. I'm thinking about switching to Jackson for my JSON parsing needs and I wonder how to possibly avoid similar issue. Is there any way to tell my app to explicitly use JAR that came with it? I'm not sure how it works but hopefully you get an idea.
Is there any way to tell my app to explicitly use JAR that came with it?
Sorry, but no. You do not control the classpath. The firmware always wins.
Most of the time, this will occur because Android itself has the third-party JAR as part of what gets loaded into each virtual machine. The Legion of the Bouncy Castle is a great example of this.
This is the first I've encountered where a device manufacturer appears to have added third-party classes to what gets loaded in each virtual machine. I will contact them and ask them to stop doing this, though I have no idea if they will listen.
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.