Develop Reference

Android Log Levels

Android supports various log levels, Verbose, Debug, Info, Warn and Error. I understand how the logging levels work; I'm more interested in the typical output expected for a given level.
For example, when developing an application I might be curious when a certain method is doing something (this often tends to be for debugging purposes). I'll look through the logs to make sure the methods are being called in an expected order, if the network response is what I think it should be, if the parsers finds the right information, etc.
Why would some one use Verbose vs Debug vs Info?
From the perspective of a developer, for a first, second, or third party application aren't all logs for debugging purposes? (assuming devs don't stare a logs for fun... I'm not that sadistic)
From the perspective of a consumer, when the s*** hits the fan and they need to contact customer support because their super important / business critical application isn't working a developer uses the log for debugging purposes.
The only reason I could see for using verbose or info is perhaps metrics gathering / data warehouse related operations. If so, why use verbose vs info.
Not sure If I'm overcomplicating this or if the android framework is...

I basically follow what Tomasz Nurkiewicz has to say when considering logging level:
ERROR – something terribly wrong had happened, that must be investigated immediately. No system can tolerate items logged on this level. Example: NPE, database unavailable, mission critical use case cannot be continued.
WARN – the process might be continued, but take extra caution. Example: “Application running in development mode” or “Administration console is not secured with a password”. The application can tolerate warning messages, but they should always be justified and examined.
INFO – Important business process has finished. In ideal world, administrator or advanced user should be able to understand INFO messages and quickly find out what the application is doing. For example if an application is all about booking airplane tickets, there should be only one INFO statement per each ticket saying “[Who] booked ticket from [Where] to [Where]“. Other definition of INFO message: each action that changes the state of the application significantly (database update, external system request).
DEBUG – Developers stuff.
VERBOSE – Very detailed information, intended only for development. You might keep trace messages for a short period of time after deployment on production environment, but treat these log statements as temporary, that should or might be turned-off eventually. The distinction between DEBUG and VERBOSE is the most difficult, but if you put logging statement and remove it after the feature has been developed and tested, it should probably be on VERBOSE level.
My most favorite level is WTF(2.2+) which is supposed to stand for "What a Terrible Failure", for situations that should never happen.
I normally use "info" for simple messages.

Routing key input to different Activities

Let me first start off by explaining my problem -
I am working on an application that is lying between the a system activity (com.google.tv.player.PlayerActivity) and user-space.
The system activity has a certain behaviour that happens when I press the MENU button. Because of my newly deployed application in-between, I am trying really hard to send that MENU keyevent to the "activity above me". Otherwise, it's just intercepted and consumed by my app.
I have no references to the activity. I have somewhat examined it's old code to figure out that the menu button press eventually calls void openOptionsMenu(); and most attempts have been fruitless. Here's a short list of what I tried, I catch the MENU press in MyActivity.onKeyDown() and tried doing the following
super.onKeyDown(keyEvent); got me really nowhere.
dispatching the key with dispatchKey caused stackoverflows depending on use
dispatching the event with menuEvent.dispatch((Activity) getRefByReflection());
grabbing the WindowManager and dispatchin the key to it.
overriding dispatchKey obviously, which just ended in a stackoverflow :)
I have read online that there is/was a way to dispatch a key via a PID - I can get the player's pid, but lack the method to use to dispatch the key! I simply have no dispatchKey(KeyEvent event, int recvPID, int recvUID) that they have seem to be using.
I am also aware that I will get a few faking user-input is shaky and it's better to refactor the button behaviour than to simulate pressing it and I agree but, I am in no position to even get the source, much less afford changes to it. Reversing it would be an option, if only to know what members I need to reflect against.
To me, it seems that there simply is no way to route the keypress as a passthru and let it sink into the activity below, so I really do have to SEND / DISPATCH it somehow. Any help would be really appreciated.
Once again, I'm looking for a way to allow pass-through of keypresses, all for sake of opening a menu that i have no way of reaching programatically through my code.
The last, not-completely-explored option is the InputManager's injectInputEvent method - but without a way of 'directing' it anywhere, I do not know if it'll bare fruit to explore that venue thoroughly. Then again, it's the only thing left to explore.
It might be worth noting that the reflection approach failed due to
Caused by: java.lang.ClassNotFoundException: Didn't find class
"com.google.tv.player.PlayerActivity" on path: /system/app/myAPK.apk
so maybe (hopefully) it's some sort of class loader issue?
I'll be awarding 100 bounty on this question as soon as I can, in the meantime - please help :) I have searched SO high and low, and tried all things suggested and what I could think of. At the moment i'm really stumped.

According to Diane Hackborne on a discussion had on android-developers mailing list quoting
From: Dianne Hackborn (hack...#android.com)
Date: Mar 11, 2011 5:24:06 pm
List: com.googlegroups.android-developers
Correct you can't do this, very much by design.
It turns out that it is a major security risk to allow foreign apps to dispatch key events to other apps. Therefore, apps that need to work together this way also need to share either the GroupID or the PID.
Conclusion: unfortunately, what you are asking doesn't seem possible at the moment.

If there is any encapsulating code you could post it would greatly help in understanding your call stack. From the description you gave my thought is that you should return false from your key handler (what ever method is actually capturing the key press) this would allow it to bubble up from the middleware you mentioned. Again I'm not sure of your key entry point since you did not provide a signature or indicate what method is trapping the key press.

If you unpack the GTV TV Player APK, the manifest references several libraries:
<uses-library android:name="com.google.android.tv" />
<uses-library android:name="com.google.tv" />
<uses-library android:name="com.google.tv.epg" />
<uses-library android:name="com.google.tv.mediadevices" />
Not sure if this will resolve the reflection class loader issue, but it is worth a try.

Do I really need to add the com.facebook.Settings.publishInstallAsync() method to all of my Activities?

I'm currently trying to make the mobile ads with facebook work for my android app.
I did all of the steps required, except the one where I need to add the method:
com.facebook.Settings.publishInstallAsync();
to all of my activities in the onResume() method.
My questions is - do I really have to put this method in ALL of my activities, and if yes - why?
I'm concerned that if I do so - my app will run slower.
Maybe if I put it in the first Launching activity only, it will still work?
Thanks :)

That method, as the name implies, runs on a different thread, so unless your app is very resource constrained, should not affect the performance. It will also handle tracking repeat calls to prevent multiple installs being reported, so once it reports on first install, it won't report again.

extras Bundle in Android Notification usage?

Although not documented in the Notification Documentation, looking at the Notification.java for Jelly Bean there is an extras Bundle with an EXTRA_PEOPLE key defined.
The type is listed as TBD, can anyone from Android provide direction as to what this may look like? Do you expect this to be a list of String names, or maybe Long rawContactIds? Will there be any recommended ordering (such as meeting organizer versus attendees, or a Gmail From versus CC)?
Are there any changes in Android 4.2 that will utilize this, or is this still truly TBD?

Even if it is filled out now, relying on it is risky- if it's labeled TBD then they can change it in any minor release without telling you, any code depending on it is likely to break. I wouldn't risk it for anything I was releasing.
If you want to test it out though, write an app that uses it and use java reflection to get the class name of the object and print out the values. If its a collection class, repeat on whatever object it holds and let us know.

Still truly TBD.
(General rule: Avoid using anything that's marked #hide unless you really know what you're doing.)

Android: Get Time Spent Per Activity

Firstly, I'm not looking for time spent on a given application. There is already "an app for that", com.android.settings/.UsageStats, and a good deal of supporting code in the AOSP frameworks/base/services/java/com/android/server/am/UsageStatsService.java, etc.
The code that I've examined so far does not seem to record elapsed time spent on particular <activity>s. I have thought to get this information two ways, but feel there must be something cleaner and simpler, that leverages more existing code. The ideas have been:
Instrument the base Activity class onPause() and onResume(), to hack in a timestamp, and log the info some place (probably a SQLite database.)
Instrument the Context class, to make note whenever startActivity() and friends are called.
So what do you think -- anything better than those options? Thank you in advance!

So what do you think -- anything better than those options?
Anything is better than #2, which requires custom firmware.
#1 is your only option within the SDK for API Level 13 on down AFAIK.
API Level 14 (a.k.a., Android 4.0) added in Application.ActivityLifecycleCallbacks, which you can register via registerActivityLifecycleCallbacks() called on your Application (e.g., getApplicationContext()). I haven't used these yet, but it would appear that you can arrange for a single listener to be notified of activities coming and going, avoiding forcing you to extend some common base Activity class with your desired logging.