Is there a way to somehow intercept calls to the standard Log in android and perform some other action?
In desktop Java one would usually get some logger so there are ways to install a different logging handler / implementation. However, Android seems to have a static call to Log, and I could not find any information about replacing the default behavior.
I realize I can monitor the device log through ADB, but I'd like to have a different behavior in running apps on a device who opt in (e.g., by executing a certain instruction when the program starts out).
As AedonEtLIRA points out Log is final so you need to roll/borrow a new one. I've been using Prasanta Paul's "MLog": http://prasanta-paul.blogspot.com/2010/07/custom-logger-for-android.html
It makes it easy to save logs to a text file and/or disable logging completely.
If it doesn't already do what you need, it is a good base for managing logging.
I think your best solution would be to replace all the Log calls in your application with your own class, MyLog, then call Log if they don't opt-in, and call your special logging feature if they opt-in.
Replacing all the Log calls shouldn't be hard, just a find and replace.
In addition to MLog proposed by #Darrell, there are several other logging frameworks for Android, including:
logback-android
log4j-android
microlog4android
Of the three, logback (the next-gen log4j) seems to be the most capable and have the richest API (and lots of documentation), while microlog is the most compact (but limited in features...but maybe it does all you need). All three support the SLF4J logging facade, so you can easily swap out microlog for logback, log4j, jul, or some newer framework down the road.
As with MLog, these frameworks require replacing the calls to android.os.util.Log (it doesn't "intercept" the calls as you might be after).
Because Log is final, I think you will have to write your own logging system and implement that if you want to change anything.
Related
I have a simple application that contains two implementations which I want to compare(benchmark) with each other in terms of usage during a certain amount of time.
The testing method is equal for both implementations (they both execute exactly the same commands/events) the only difference is the way they process the command and events.
I wish to get a log per second of:
CPU load
Memory usage
Network traffic
The Android Monitor provides everything I need in a graph and logs per second the current CPU load, Memory usage and the TX/RX for network traffic, great!
However I wish to have this all in a text log instead of a live graph. Can someone tell me where I could find such a log? OR if there is no such thing, any suggestions to get similar data?
Doppie, I looked for a solution using out-of-box tools, but there is no good way to use the Android tools to export just the information you want to a text file without lots of work. Logcat is way too verbose and requires conversion, and Dalvik doesn't exactly provide you the every-second control over data collection. I would love to have a simple solution for this too. :/
[Disclaimer: Because I work with Perfecto, I know that the devices in their cloud lab can do this easily, so if you are trying to diagnose a specific problem, you could use their free public cloud and export the device vitals (shown below). This is not a pitch, but since it's free to play, it might help you in the short-term.]
hi first of all if you looking for memory logs. There is one option you can directly go and check that one.
Open Android Device Monitor then checks heap dumps.Check the uses of memory.
Another way to monitor Android Device Monitor then see the Allocation Tracker it gives you details in everyclass where you memory is used.
Expect these things you can directly check your Current logs.
Click Android Monitor and see logcat and second option Monitors.
Monitors gives you Four type of details :
1. Memory usages.
2. CPU how kuch usages of your phone.
3. Network
4. GPU.
Now after these all things. If you still have some problem then need to check your gradle.
What kind of libraries you used.
First of all remove unwanted libraries.
Secondly need to import only useful libraries. Like if you looking for map related things in your app then import only.
compile "com.google.android.gms:play-services-maps:9.4.0"
not this one.
compile 'com.google.android.gms:play-services:9.4.0'
Aware about replication of libraries.
Example : If you using some libraries and that libaray contain appcompt and you are also using same libaray in your app side.Then its better to use that libaray as module.
At last try to use proguard rules.
These are few ways to handle better memory management.
I have made one android app architecture here is link..
Thanks hope this will help you.
I want to call functions provided in com_android_bluetooth_hid.cpp in android source from my own app. Target Android versions are >=4.4 and <=5.x. I understand JNI, and can compile my own code and call from my own app.
Would it be possible to call android's library from my app? How
Also, to call functions in that specific cpp file, are BLUETOOTH and BLUETOOTH_ADMIN permissions sufficient or something else (other permission, or root) would be required?
The cleanest way to call Android's CPP code is, generally, copying the relevant pieces to your repository and building as part of your app. Following this approach, your app will only call the public APIs - either Java or C/C++.
But this may not be relevant in cases when this code must run with special permissions, as system service, like mediaserver or Bluetooth stack.
I am afraid that the code you wish to run belongs to this second category, therefore none of the available tricks will not help.
On the other hand, a custom ROM may be a solution you are looking for. It may happen that you don't need to forge a full system. It may be enough to use a rooted device and replace the bluetooth service with your custom one.
I would still advise you to provide the missing callbacks for the service, instead of calling the functions directly from your app: you better not mix contexts between a user-space app and system service.
Even a private member/function of my class can be accessed by reflection by using setAccessible(true). Is there a way to prevent this kind of access from outside code?
I read something, here on stack-overflow, that I can use SecurityManager for prevention of reflection in applets(not sure how it works, though), but is there a similar mechanism for Android as well? Maybe an annotation or clever-programming?
Taking a step back, what you're observing is a difference in security philosophy, between the Java execution model as originally embodied in JVMs at Sun and the execution model of Android.
The original Java VM design was intended for a system wherein multiple, mutually-suspicious applications (or "applets" in the Java parlance) would simultaneously inhabit a single address space, running in a single VM. Because the designers didn't want one app to be able to mess with another, they went through great pains to define an intra-VM security model that would disallow things such as one object touching the private fields of another object of a different class.
That said, the Java library ended up having various "escape hatches" out of the security model. One of those is setAccessible() on reflection objects, as you note.
Android's model is different: Android uses processes as the security boundary and unit of application isolation, instead of trying to insinuate it into the process as was done with traditional JVMs. This renders moot the entirety of the Java security model, except in that it helps an application "save it from itself." That is, it's good design to not have an object poke into another object's private parts, and the default Java security model provides just that.
Leaving aside the question of people modifying your code, with Android, as an application author, you control all the code that ends up running inside the process of your app. If you choose to include code that calls setAccessible() that's your business. You might be shooting yourself in the foot, but you certainly won't be shooting any other apps' feet, since the Android security model, running as it as at the layer of processes, inherently doesn't let that happen. Likewise, using native code will totally break you out of the Java object model, which allows for the possibility of things going totally higgledy-piggledy in the process but also allows you to express some things in a more productive manner than you could in Java. It's a trade-off, but it's a per-application-developer tradeoff and not one that particularly impacts anything else that's happening on your phone / device.
I know this doesn't directly answer your question, but I hope it provided some useful context.
Is there a way to prevent this kind of access from outside code?
Not really.
is there a similar mechanism for Android as well?
Even if there is (and I am not aware that such a thing exists), anyone can remove it, by decompiling your code (assuming they do not have your source already), getting rid of the protection, and recompiling the code.
Bear in mind that ProGuard, when used properly, will obfuscate your private classes and methods for your production APK builds. That, plus a lack of documentation, will make it tedious for anyone to gain access to those private classes and methods.
I don't believe that you can ever really 100% protect from users using reflection on your project with malicious intent. You can make it more difficult for users to do it by doing things like obfuscating your code, but it is still possible to reflect on the obfuscated code.
I don't believe SecurityManager can be used for the purpose that you are suggesting, though I could be wrong.
What is happening under the hood? somehow this is passed down to the OS, and someshow the OS will find the right activity / activities, and launch it? Is there a service / lib running in Android handling this? I am trying to modified the OS to override the logic of startActivity across the board, is this possible?
Thanks.
I would take a look at the Android source! Whenever I'm developing and I run into an issue I read through the source to discover what is happening under the hood; it's quite interesting! It's an insight into what's actually going on, and also very good guidelines for documentation and code formatting!
http://source.android.com/source/downloading.html
A good starting point might be ActivityManagerService
Basically, when an app is first launched, startProcessLocked() in ActivityManagerService creates a new ProcessRecord (if necessary) and then calls Process.start(), which in turns builds the arguments for zygote and sends to zygote's socket using zygoteSendArgsAndGetResult(). Of course there's more to it than that, for example if an app shares a uid, is isolated, etc. But that gives you the basic process.
Looking over the source is indeed a good way to understand what's going on. However, unless you're planning on modifying it, don't bother downloading AOSP, just use GrepCode. Easier to browse, search and everything is hyperlinked so it's easy to follow through to classes, find usages, derived methods, etc. If you download AOSP, you'll be stuck with grep, ack-grep if you're lucky and a text editor. Also, you'll only have the one version you picked to checkout. GrepCode has the code for almost every version since 1.5.
The linked text above will take you to the relevant source at GrepCode. Try it out! The only downside is that GrepCode doesn't include the native C++ layer.
I'm an old school developer (OK, I'm 20, I'm not old school, I just like printing it out instead of using the step-by-step debugger :P ) and I have a lot of Log.i() calls in an Android application. I was wondering if it would have an impact on the performance of the app?
I know I should use a step-by-step debugger, it's just that debugging multiple threads can be a little cumbersome.
Thanks for your help!
I don't think Log will affect to application performance, because when release app, you turn off it in Android Manifest by setting debuggable:
<application android:icon="#drawable/icon"
android:label="#string/app_name"
android:debuggable="false">
I'm still looking into Android coding myself but I from what I've seen so far I would assume that the Android logging suffers from the same issues that most Java logging frameworks suffer from (The notable exception being SLF4J), namely:
Logging does effect performance because:
It means extra method calls. (Not an issue for 99% of apps).
It often means String assembly work (Big impact)
It engages extra IO (Big impact)
Developers typically deal with this by adding guard blocks
if (log.isDebugEnabled()) {
log.debug("...");
}
I think the Android SDK can do this as well. it covers off #2 and #3, but still leaves your release code containing unused logging code. assuming of course that you never want to enable debug logging in a release situation.
SFL4J BTW, doesn't require guard blocks because it used C like method calls which delay String assembly until it's actually required. Unfortunately it appears that Android has not gone down this path. iOS doesn't have this problem either because it has a pre-compiler. Something that I often wish Java had kept.
Anyway, I would not advocate removing logging in favour of the debugger. IMHO they server two different purposes. Logging I find very useful (if done properly) in understanding the flow of an application. I've often found problems by looking through logs that I would not have found in the debugger. Ie. unnecessary code execution across multiple classes (especially in UI classes), odd data issues that don't lead to actually bugs, etc. In these situations using the debugger would be like trying to lay concrete with a spoon. Debuggers on the other hand are perfect for analysing the fine details of an issue highlighted by the logging.
So in my code I tend to have a fair amount of logging which is designed to tell me what the application is doing, in an English like manner so I can read it easily and understand what is happening. But I'm fairly strict about keeping the levels as low as possible. Ie. don't log stuff at the info level unless it's something you want to see even in release mode. I've found a lot of developers tend to break this.
UPDATE: Just read Remove all debug logging calls before publishing: are there tools to do this? which talks about how you can use ProGuard to strip logging from release code. Great idea, means you can not bother with guard blocks on logging and put as much in as you like, yet still be assured that your release code will be fast.
If you switch to Log.d, then you can debug your application, and when building a release version, none of those calls will be compiled or executed.
Yes, it does have performance penalty. check this: Log.d and impact on performance
The answer is yes and no.
It depends on how many Log calls you have and as you're talking about step-debugging, I'm guessing you're not worried about release code at this stage (when you'd obviously remove excessive logging).
I've used excessive logging to the point it overflows the logcat but only when trying to track down a particularly elusive problem in my debug code - that logging was removed as soon as I tracked the problem down.
In short, log as much as you like in development but don't inflict it on the user.