Without additional annotations, static analysis is going to warn that both
the Context and Intent may be null. This is due to the fact that the
broadcast receiver is an instantiable class and onReceive() is a public
method. For example:
new MyBroadcastReceiver().onReceive(null, null);
Adding
You and I agree again ;-)
On Monday, July 15, 2013 5:19:17 AM UTC+3, TreKing wrote:
On Sun, Jul 14, 2013 at 5:22 PM, Palmer Eldritch
the@gmail.comjavascript:
wrote:
Have you thought that this could be a way of delving a bit deeper into
the framework ? That, well, it's not the end
I've played around with some tools that do static analysis, one of the
bigger developers that deal with those tools also ran some beta testing
with us for a toolset for Android.
Seems like this isn't even close to being a big help... a short while after
i just stopped using it.
Other than
Have you thought that this could be a way of delving a bit deeper into the
framework ? That, well, it's not the end result only but the search that
matters ?
If that's the case, why are you asking a question here?
you already have the sources, go through them ... browse through all the
Quite interesting. Thanks for elaborating.
On Sun, Jul 14, 2013 at 11:56 PM, Kristopher Micinski
krismicin...@gmail.com wrote:
At the risk of being too tangential... null pointer analysis is a very
popular static analysis. Tons of Java based static analysis engines
implement it using any
You should null check every intent and every property on the intent.
Some crash security studies on Android show that these areas are where a
significant amount of errors (30% in some cases) are occurring.
On Tuesday, July 9, 2013 7:46:41 AM UTC-5, Palmer Eldritch wrote:
In other words :
On Mon, Jul 15, 2013 at 3:20 AM, Piren gpi...@gmail.com wrote:
I've played around with some tools that do static analysis, one of the
bigger developers that deal with those tools also ran some beta testing
with us for a toolset for Android.
Seems like this isn't even close to being a big
I agree with pretty much with everything you said, but:
-Since this is Android Developers, we can probably agree that current
static analysis tools for android are not that helpful for the vast
majority of applications... I did not try to imply it is worthless for
everyone :)
- I also didnt
On Mon, Jul 15, 2013 at 9:55 AM, Piren gpi...@gmail.com wrote:
I agree with pretty much with everything you said, but:
-Since this is Android Developers, we can probably agree that current static
analysis tools for android are not that helpful for the vast majority of
applications... I did
ahh... too many links for me to actually want to go through ;-)
The first one is just a search, what's not to get there? It shows places
where it found your search according to their source branch version and
other (what it thinks are) related searches.
all the rest doesn't really matter.. who
On Sun, Jul 14, 2013 at 2:02 AM, Piren gpi...@gmail.com wrote:
It's actually funny you care so much about it...if you'd go to such
lengths to check such a minor thing, how can you get any code done?
Took the words right out of my mouth. :)
This is quite the effort to avoid a simple if
Glad you agree with each other
Have you thought that this could be a way of delving a bit deeper into the
framework ? That, well, it's not the end result only but the search that
matters ?
And that maybe this way one writes code faster at the end cause one knows
his/her way better ?
No
The framework code that Piren posted a link to above (below?) accesses
the Intent object before calling the receiver's onReceive:
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/app/ActivityThread.java#2350
Line 2350:
I think the point everyone is trying to make is that it's important to
care about statically ruling certain invariants are met: that's not an
inherently bad thing.
But with Android it's impossible to know if this invariant can be
statically determined: since you never know which ROM you're
On Sun, Jul 14, 2013 at 5:22 PM, Palmer Eldritch the.u...@gmail.com wrote:
Have you thought that this could be a way of delving a bit deeper into the
framework ? That, well, it's not the end result only but the search that
matters ?
If what you're saying is that this is an academic endeavor
On Sun, Jul 14, 2013 at 10:19 PM, TreKing treking...@gmail.com wrote:
On Sun, Jul 14, 2013 at 5:22 PM, Palmer Eldritch the.u...@gmail.com wrote:
Receiving an object one hasn't the slightest idea about is apparently the
android way - may be null or not - who cares as long as we can add an if
On Sun, Jul 14, 2013 at 10:08 PM, Kristopher Micinski
krismicin...@gmail.com wrote:
I think this is probably a valid thing to consider in most APIs,
especially if they're statically linked APIs, where you can actually check.
Going off topic a bit, but maybe this will be of interest to the OP
At the risk of being too tangential... null pointer analysis is a very
popular static analysis. Tons of Java based static analysis engines
implement it using any off the shelf techniques: abstract
interpretation (execute a piece of the program which carries an
abstract value saying this is null
No point of being sure here... even if the current code is structured in a
way that it shouldn't be null, nothing says it will stay like that in all
future code revisions.
Ever since i started getting null exceptions from android (not
NullPointerException... a Null instead of an exception) i
That's nice advice - but in this case I think one should have a guarantee
Does it make sense to receive a null intent ? Is it even possible with the
current android code ?
On Thursday, July 11, 2013 9:46:00 AM UTC+3, Piren wrote:
No point of being sure here... even if the current code is
i'm pretty sure it's impossible to guarantee something like that... i don't
think part of their new programmer orientation is if you ever touch the
code that runs BroadcastReceiver.onReceive...never send a null intent.
Either way, at least on android 4.2.2_r1, it seems like it's impossible to
a this is a step to the right direction ;)
notice they don't check for null
now any places the ReceiverData object is initialized ?
btw search in grepcode Sucks big time ! could you in the name of Mordor
tell me what I should make out from here :
I mean nobody knows ??
Do you ever check the intent for being null and if not why ?
On Tuesday, July 9, 2013 3:46:41 PM UTC+3, Palmer Eldritch wrote:
In other words :
@Override
public void onReceive(Context context, Intent intent) {
final String action = intent.getAction();
On Wed, Jul 10, 2013 at 4:14 PM, Palmer Eldritch the.u...@gmail.com wrote:
I mean nobody knows ??
Do you ever check the intent for being null and if not why ?
Here's what you do. Assume it will not be null, then use ACRA or some other
bug-reporting tool to handle uncaught exceptions. If you
I suspect it can't be null *by construction* - I just can't pin it down in
code (or in docs)
It's nice to be sure
Can somebody point to the relevant code parts ?
I mean what paths lead to the onReceive being triggered ? Can we have a
null intent in any of them ?
On Thursday, July 11, 2013
25 matches
Mail list logo
