Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This is far away from trivial but should work when the apps you want to monitor use sqlite databases or, more generic, write messages to a file when they arrive.</p> <p>You will indeed need to have root access to the device as this violates the android security system:</p> <p>Write a native process which runs as a daemon with the NDK and spawn it once after boot as root. You have now 3 major problems to solve:</p> <p><strong>How to find out if something changed?</strong></p> <p>This is the easy part. You would need to utilize the linux inotify interface which should be accessable on every android phone as the SDK has a <a href="http://developer.android.com/reference/android/os/FileObserver.html" rel="nofollow">FileObserver</a> since API 1, so you are on the save side here. </p> <p>Another interesting thing may be to catch the C2DM messages. I have found a NDK class which is called <a href="http://code.google.com/p/android-cpp-sdk/source/browse/trunk/android-cpp-sdk/platforms/android-4/android/content/BroadcastReceiver.hpp?spec=svn52&amp;r=52" rel="nofollow">BroadcastReceiver</a>, so the NDK may be able to catch them. But I personally wouldn't do that, it feels wrong to steal intents. Also you would have to redistribute them or let them travel to real recipient, so I will not describe this in detail here. It may work, but it may be harder and should only be a fallback.</p> <p>So, when you have solved this, the next problem arises:</p> <p><strong>How to read the changes in a save way?</strong></p> <p>You have a problem, a big one, here. The file doesn't belong to you, you doesn't even have the right to know where it is (normally). So the monitored app is not aware of you and will act like the file is exclusively owned by it. If they use some plain old textfile to write messages to you have to find out a way to read from it safely as it may be overwritten or extended at any time. But you may be lucky when they use sqlite, according to <a href="http://www.sqlite.org/faq.html#q5" rel="nofollow">this</a> it's totally valid to have more than one simultaneous reader, just only one writer. We are in the specs, everything fine again. When you have now read out the new data, more problems to solve:</p> <p><strong>How to get the new data back into the main app?</strong></p> <p>You should do only the bare minimum in this c/c++ program because it runs as root. You should also protect your app users from security breaches, so please program the daemon with this in mind. I have no real idea for this could work really good, but here are some them:</p> <ul> <li>Write the collected data into your own sqlite database (easy in c/c++ and java)</li> <li>Write the collected data into a plain file (not recommended at all, pain in the rear)</li> <li>Send an Intent which contains the new data (maybe not that easy in c/c++, but easy in java)</li> <li>Sockets/pipes/..., just every rpc mechanism you could imagine which is brought to you by linux (same as the file, don't do it)</li> </ul> <p>As stated in the text above, please be careful when you write this daemon as it is a potential security hazard. Also it may be hard to do this when you have no knowledge about c/c++ at all, and even when you have written simple programs this should be a non trivial task.</p> <p>On my search through the web I have found this NDK c++ classes I mentioned above. It can be found at <a href="http://code.google.com/p/android-cpp-sdk/" rel="nofollow">google code</a>. I have no experience with the NDK nor with the c++ wrapper but it may be worth a look when you plan to write this. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload