[android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[James Wald]

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 @NonNull to the two parameters will allow you to forego null checks, 
but you better hope the framework never calls onReceive() with null 
arguments.

On Tuesday, July 9, 2013 2:46:41 AM UTC-10, Mr&Mrs D wrote:
>
> In other words :
>
> @Override
> public void onReceive(Context context, Intent intent) {
> final String action = intent.getAction(); // can intent==null here 
> ?
> }
>
> I need to solve this once and for all so please no ifs and buts. I would 
> check for null but I suspect that it is not needed and therefore it is 
> clumsy and inelegant to check. I had searched in the docs but have not 
> found anything
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Kristopher Micinski]

On Mon, Jul 15, 2013 at 9:55 AM, Piren  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 not try to imply it is worthless for everyone :)
>
> - I also didnt imply that static analysis is supposed to test UI, these are
> a whole different set of tools as both of us agree. But static analysis can
> be used to figure out if the UI model works with the codebehind it has. I'm
> not looking for correctness of intended used, but the correctness of the
> implemented code, with relation to its attached UI. This is exactly what
> google are doing little by little with LINT.
>
> - My last paragraph meant exactly what you said... Since the code does not
> have the proper summaries (as the OP mentioned), static analysis tools would
> still need to parse the source just to tell whether a returned value will
> actually return. If anything, if an SA tool would rely on google apis, there
> would probably be quite a bit of mistakes due to the fact some of the
> documentation is just wrong.
>
> In short - SA is very cool, but not very useful currently for the average
> android developer :)

Great!  I just wanted to alleviate the aversion to using static
analysis for anything, as many people do.

Just a small (hopefully not too tangential comment) from your last
paragraph.  Static analysis API summaries are almost never generated
from documentation for exactly this reason: people very often find the
documentation is plain wrong when doing analysis.  Generally people
will write annotations for static analyzers using a mix of different
ad hoc techniques (there is, of course, some work that aims to fix
this, but it's not production ready).  In particular, while
documentation works for some things (e.g., what should be called when,
etc...), it can't usually specify finer grained things needed to make
analysis work (e.g., nearly every analysis for java relies on a
points-to graph, which is never written down in documentation).

There are, at this time, some (rumored to be) production ready tools
for Android: previous attempts mostly take Java SA and shoehorn it on
to the Android API:

 - http://www.juliasoft.com/
 - https://dexter.bluebox.com/

I can't vouch for either very thoroughly, but given the amount of
funding pushed by various organizations, I feel confident more will
pop up in the future.

Kris

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Piren]

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 imply that static analysis is supposed to test UI, these are 
a whole different set of tools as both of us agree. But static analysis can 
be used to figure out if the UI model works with the codebehind it has. I'm 
not looking for correctness of intended used, but the correctness of the 
implemented code, with relation to its attached UI. This is exactly what 
google are doing little by little with LINT.

- My last paragraph meant exactly what you said... Since the code does not 
have the proper summaries (as the OP mentioned), static analysis tools 
would still need to parse the source just to tell whether a returned value 
will actually return. If anything, if an SA tool would rely on google apis, 
there would probably be quite a bit of mistakes due to the fact some of the 
documentation is just wrong.

In short - SA is very cool, but not very useful currently for the average 
android developer :)



On Monday, July 15, 2013 3:04:31 PM UTC+3, Kristopher Micinski wrote:
>
> On Mon, Jul 15, 2013 at 3:20 AM, Piren > 
> 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 help... a short while 
> after 
> > i just stopped using it. 
> > 
>
> As an FYI, my research is (in part) driven by static analysis (for 
> Android apps); since there's a lot of FUD surrounding it I'd like to 
> try to dispel as much as I can. 
>
> This is most people's impression about static analysis, but usually 
> because they're using bad tools.  Integrating static analysis into 
> your production cycle is complicated (because the tools are 
> complicated) and usually something that doesn't pay off since the need 
> for correctness on Android is almost never life threatening. 
>
> By contrast, the use of static analysis is generally involved in some 
> very core code, and the rest is tested using a much more traditional 
> development methodology.  (E.g., you may want to verify security 
> related parts of your app dealing with information leakage, but the 
> UI, etc.., can be tested.) 
>
> > Other than pointing out some very glaring design decisions, it wasn't 
> really 
> > helpful at all. This is especially true since it can only check the M 
> and C 
> > parts of the MVC design model and has big issues making sure they work 
> well 
> > with the V. 
>
> This is by no means all of static analysis, but it does highlight the 
> current scope of Android: people take production tools verbatim and 
> apply them to the Android API.  A major part of what I said applies 
> here: static analysis isn't *meant* to test UI.  There are 
> technologies that do this, but they aren't the norm, and most suites 
> don't focus production on those since they are hard to get right. 
> (I.e., testing UI vs. model integration is already somewhat hard on 
> Android to begin with, adding in the vast numbers of configuration 
> options makes it much harder in the static case.) 
>
> > I also doubt they'd be able to check the Android API without actually 
> > attaching it's entire source (in java and c++, and in all possible 
> > configurations and ROM variants) and compiling the whole thing. So 
> either 
> > way, even with these tools, the OP won't get any real answer. 
>
> This isn't true either, most real static analyses rely on API 
> summaries: doing so would include millions of lines of code.  At the 
> current state of the art, there are ways to derive API summaries in a 
> pretty efficient and systematic manner.  While it's very hard to do so 
> (lots of manual labor involved in writing a correct API spec) it's 
> definitely the most important part of a static analysis for real world 
> applications. 
>
> It's true that with some static analysis engines you won't get an 
> immediate answer, but it's patently false that no tools can offer such 
> an answer.  (However, it may be true that no currently existing static 
> analysis tool has sufficient coverage of the Android API.) 
>
> Kris 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-develop

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Kristopher Micinski]

On Mon, Jul 15, 2013 at 3:20 AM, Piren  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 help... a short while after
> i just stopped using it.
>

As an FYI, my research is (in part) driven by static analysis (for
Android apps); since there's a lot of FUD surrounding it I'd like to
try to dispel as much as I can.

This is most people's impression about static analysis, but usually
because they're using bad tools.  Integrating static analysis into
your production cycle is complicated (because the tools are
complicated) and usually something that doesn't pay off since the need
for correctness on Android is almost never life threatening.

By contrast, the use of static analysis is generally involved in some
very core code, and the rest is tested using a much more traditional
development methodology.  (E.g., you may want to verify security
related parts of your app dealing with information leakage, but the
UI, etc.., can be tested.)

> Other than pointing out some very glaring design decisions, it wasn't really
> helpful at all. This is especially true since it can only check the M and C
> parts of the MVC design model and has big issues making sure they work well
> with the V.

This is by no means all of static analysis, but it does highlight the
current scope of Android: people take production tools verbatim and
apply them to the Android API.  A major part of what I said applies
here: static analysis isn't *meant* to test UI.  There are
technologies that do this, but they aren't the norm, and most suites
don't focus production on those since they are hard to get right.
(I.e., testing UI vs. model integration is already somewhat hard on
Android to begin with, adding in the vast numbers of configuration
options makes it much harder in the static case.)

> I also doubt they'd be able to check the Android API without actually
> attaching it's entire source (in java and c++, and in all possible
> configurations and ROM variants) and compiling the whole thing. So either
> way, even with these tools, the OP won't get any real answer.

This isn't true either, most real static analyses rely on API
summaries: doing so would include millions of lines of code.  At the
current state of the art, there are ways to derive API summaries in a
pretty efficient and systematic manner.  While it's very hard to do so
(lots of manual labor involved in writing a correct API spec) it's
definitely the most important part of a static analysis for real world
applications.

It's true that with some static analysis engines you won't get an
immediate answer, but it's patently false that no tools can offer such
an answer.  (However, it may be true that no currently existing static
analysis tool has sufficient coverage of the Android API.)

Kris

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Brad Dennis]

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 :
>
> @Override
> public void onReceive(Context context, Intent intent) {
> final String action = intent.getAction(); // can intent==null here 
> ?
> }
>
> I need to solve this once and for all so please no ifs and buts. I would 
> check for null but I suspect that it is not needed and therefore it is 
> clumsy and inelegant to check. I had searched in the docs but have not 
> found anything
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[TreKing]

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 off the shelf techniques: abstract
> interpretation (execute a piece of the program which carries an
> abstract value saying "this is null" or "this is not null"),
> constraint based analyses (draw a bunch of constraints from the
> program text which correspond to how pointers propagate), or some
> simpler ad hoc techniques.
>
> The basic idea is pretty simple: you look at the set of possible
> things a reference could point to, and if it's ever possible that
> thing can be null, you treat it that way.
>
> E.g.,
>
> if (..) {
>   x = thing1
> }
> else {
>   y = null;
> }
> p = x;
>
> would mean, if x can be null, then p can be null (so not here, but
> would be if the else assigned to x instead).  Then you propagate
> changes throughout the program, again and again until you cover
> everything.  Constraint solving does the same thing, but phrased as a
> set of constraints which have to be solved.
>
> Since this is wildly imprecise you need to employ some strategies to
> refine it.
>
> E.g.,
>
> if (some_very_hard_to_solve_arithmetic_formula_that_is_false_here) {
>p = null;
> }
>
> Will generally cause static analysis to give the wrong answer (saying
> p may be null when in fact it never will be)
>
> --
>
> What this means in the real world is that you can take FindBugs and
> run it on your program.  Findbugs isn't a complete analysis (it will
> sometimes fail to report bugs when they *are* there), but it's very
> usable and well tuned for production java code.
>
> Kris
>
> On Mon, Jul 15, 2013 at 12:28 AM, TreKing  wrote:
> >
> > On Sun, Jul 14, 2013 at 10:08 PM, Kristopher Micinski
> >  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 as
> well,
> > given the subject matter.
> >
> > I'm curious as to how you check a statically linked library for
> conditions
> > like this. So if I have some statically linked lib "Foo.jar" with some
> > method "public void Bar(SomeObject object)", I can do some check to
> verify
> > that "object" may or may not be null when used in my code?
> >
> >
> >
> -
> > TreKing - Chicago transit tracking app for Android-powered devices
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/android-developers?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Android Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to android-developers+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 

-
TreKing  - Chicago
transit tracking app for Android-powered devices

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more opt

[android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Piren]

>
> 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 
files (think of the Meme) and let us know what you found. And again, don't 
forget to go through every possible ROM there is, just to make sure.

And again, as i pointed out (and Kostya reiterated), at least for android 
4.2.2_r1, you'll never get a null. There we go - you academic endeavor is 
complete.

I think i'll still skip the links, from my experience, i find that i code 
much much faster if i say "fuck google" and instead of spending days 
code-diving through their source code, i assume they fucked up and just 
make sure my code is all safe and pretty.

Here, you can quote me on this: 

> Using Android is like picking up a woman at a sleazy bar, you'd be better 
> of putting on a rubber than trying to figure out her sexual history.

Piren, 2013.


On Monday, July 15, 2013 1:22:01 AM UTC+3, Palmer Eldritch wrote:
>
> 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
>
> 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
>
> Even in one of the most fundamental callbacks
>
> Maybe have a look at my links after all ?
>
> 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(); // can intent==null 
>> here ?
>> }
>>
>> I need to solve this once and for all so please no ifs and buts. I would 
>> check for null but I suspect that it is not needed and therefore it is 
>> clumsy and inelegant to check. I had searched in the docs but have not 
>> found anything
>>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Piren]

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 pointing out some very glaring design decisions, it wasn't 
really helpful at all. This is especially true since it can only check the 
M and C parts of the MVC design model and has big issues making sure they 
work well with the V.

I also doubt they'd be able to check the Android API without actually 
attaching it's entire source (in java and c++, and in all possible 
configurations and ROM variants) and compiling the whole thing. So either 
way, even with these tools, the OP won't get any real answer.

On Monday, July 15, 2013 7:56:07 AM UTC+3, Kristopher Micinski 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 off the shelf techniques: abstract 
> interpretation (execute a piece of the program which carries an 
> abstract value saying "this is null" or "this is not null"), 
> constraint based analyses (draw a bunch of constraints from the 
> program text which correspond to how pointers propagate), or some 
> simpler ad hoc techniques. 
>
> The basic idea is pretty simple: you look at the set of possible 
> things a reference could point to, and if it's ever possible that 
> thing can be null, you treat it that way. 
>
> E.g., 
>
> if (..) { 
>   x = thing1 
> } 
> else { 
>   y = null; 
> } 
> p = x; 
>
> would mean, if x can be null, then p can be null (so not here, but 
> would be if the else assigned to x instead).  Then you propagate 
> changes throughout the program, again and again until you cover 
> everything.  Constraint solving does the same thing, but phrased as a 
> set of constraints which have to be solved. 
>
> Since this is wildly imprecise you need to employ some strategies to 
> refine it. 
>
> E.g., 
>
> if (some_very_hard_to_solve_arithmetic_formula_that_is_false_here) { 
>p = null; 
> } 
>
> Will generally cause static analysis to give the wrong answer (saying 
> p may be null when in fact it never will be) 
>
> -- 
>
> What this means in the real world is that you can take FindBugs and 
> run it on your program.  Findbugs isn't a complete analysis (it will 
> sometimes fail to report bugs when they *are* there), but it's very 
> usable and well tuned for production java code. 
>
> Kris 
>
> On Mon, Jul 15, 2013 at 12:28 AM, TreKing > 
> wrote: 
> > 
> > On Sun, Jul 14, 2013 at 10:08 PM, Kristopher Micinski 
> > > 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 as 
> well, 
> > given the subject matter. 
> > 
> > I'm curious as to how you check a statically linked library for 
> conditions 
> > like this. So if I have some statically linked lib "Foo.jar" with some 
> > method "public void Bar(SomeObject object)", I can do some check to 
> verify 
> > that "object" may or may not be null when used in my code? 
> > 
> > 
> > 
> -
>  
>
> > TreKing - Chicago transit tracking app for Android-powered devices 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Android Developers" group. 
> > To post to this group, send email to 
> > android-d...@googlegroups.com 
> > To unsubscribe from this group, send email to 
> > android-developers+unsubscr...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/android-developers?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Android Developers" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to android-developers+unsubscr...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Piren]

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 
> 
> > 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 your part 
> and you're doing it to learn, then OK - go nuts, it's your time.
>  
>
>> And that maybe this way one writes code faster at the end cause one knows 
>> his/her way better ?
>>
>
> I don't see how determining if one specific function in the Android 
> framework can potentially send a null variable will make you write code 
> faster. In fact, one could argue that the amount of time you've spent on 
> this has made your code-writing drastically slower =P
>  
>
>> 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
>>
>
> This is not the "Android way" - this is the "programming against any 
> library ever created" way. Anytime you use any library that you yourself 
> did not write or have the source to, and is not clearly documented, you 
> will have the same issue.
>
> Now I'm just curious why you're so invested in this one function and if 
> you spend this much time determining the validity of every variable you get 
> in every method you employ from every external library you use? If not, why 
> the fascination with this one method?
>
>
> -
> TreKing  - Chicago 
> transit tracking app for Android-powered devices
>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Kristopher Micinski]

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" or "this is not null"),
constraint based analyses (draw a bunch of constraints from the
program text which correspond to how pointers propagate), or some
simpler ad hoc techniques.

The basic idea is pretty simple: you look at the set of possible
things a reference could point to, and if it's ever possible that
thing can be null, you treat it that way.

E.g.,

if (..) {
  x = thing1
}
else {
  y = null;
}
p = x;

would mean, if x can be null, then p can be null (so not here, but
would be if the else assigned to x instead).  Then you propagate
changes throughout the program, again and again until you cover
everything.  Constraint solving does the same thing, but phrased as a
set of constraints which have to be solved.

Since this is wildly imprecise you need to employ some strategies to refine it.

E.g.,

if (some_very_hard_to_solve_arithmetic_formula_that_is_false_here) {
   p = null;
}

Will generally cause static analysis to give the wrong answer (saying
p may be null when in fact it never will be)

-- 

What this means in the real world is that you can take FindBugs and
run it on your program.  Findbugs isn't a complete analysis (it will
sometimes fail to report bugs when they *are* there), but it's very
usable and well tuned for production java code.

Kris

On Mon, Jul 15, 2013 at 12:28 AM, TreKing  wrote:
>
> On Sun, Jul 14, 2013 at 10:08 PM, Kristopher Micinski
>  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 as well,
> given the subject matter.
>
> I'm curious as to how you check a statically linked library for conditions
> like this. So if I have some statically linked lib "Foo.jar" with some
> method "public void Bar(SomeObject object)", I can do some check to verify
> that "object" may or may not be null when used in my code?
>
>
> -
> TreKing - Chicago transit tracking app for Android-powered devices
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[TreKing]

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 as
well, given the subject matter.

I'm curious as to how you check a statically linked library for conditions
like this. So if I have some statically linked lib "Foo.jar" with some
method "public void Bar(SomeObject object)", I can do some check to verify
that "object" may or may not be null when used in my code?

-
TreKing  - Chicago
transit tracking app for Android-powered devices

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Kristopher Micinski]

On Sun, Jul 14, 2013 at 10:19 PM, TreKing  wrote:
>
> On Sun, Jul 14, 2013 at 5:22 PM, Palmer Eldritch  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
>
>
> This is not the "Android way" - this is the "programming against any library
> ever created" way. Anytime you use any library that you yourself did not
> write or have the source to, and is not clearly documented, you will have
> the same issue.
>
> Now I'm just curious why you're so invested in this one function and if you
> spend this much time determining the validity of every variable you get in
> every method you employ from every external library you use? If not, why the
> fascination with this one method?

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. The documentation should also specify the conditions under
which this should happen, to be fair.

I think the problem here is something that should be clarified in the
documentation,  I'd assume since it's not you should follow the safe
practice of checking values or letting them crash and get reports
after testing on your end with a test suite.  But again, this is much
more to do with the dynamically linked nature of the Android
framework, as opposed to a static library (where you usually *can*
check what the case is).

Kris

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[TreKing]

On Sun, Jul 14, 2013 at 5:22 PM, Palmer Eldritch  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 your part and
you're doing it to learn, then OK - go nuts, it's your time.


> And that maybe this way one writes code faster at the end cause one knows
> his/her way better ?
>

I don't see how determining if one specific function in the Android
framework can potentially send a null variable will make you write code
faster. In fact, one could argue that the amount of time you've spent on
this has made your code-writing drastically slower =P


> 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
>

This is not the "Android way" - this is the "programming against any
library ever created" way. Anytime you use any library that you yourself
did not write or have the source to, and is not clearly documented, you
will have the same issue.

Now I'm just curious why you're so invested in this one function and if you
spend this much time determining the validity of every variable you get in
every method you employ from every external library you use? If not, why
the fascination with this one method?

-
TreKing  - Chicago
transit tracking app for Android-powered devices

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Kristopher Micinski]

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 running
under.  My intuition is that on vanilla Android you will never see a
null intent passed to a framework method, I think I've seen the result
of a static analysis which has said this before.

But when you're running "in the wild" you never know the contents of
the dynamically linked code.  So what everyone is saying is that in
practice it seems to be that this "never" happens, but on flakey ROMs,
you never know what can happen.  (And you *can't* statically determine
this for all of them, anyway...)

Avoiding crashes is a numbers game..

Kris

On Sun, Jul 14, 2013 at 6:22 PM, Palmer Eldritch  wrote:
> 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
>
> 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
>
> Even in one of the most fundamental callbacks
>
> Maybe have a look at my links after all ?
>
>
> 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(); // can intent==null here
>> ?
>> }
>>
>> I need to solve this once and for all so please no ifs and buts. I would
>> check for null but I suspect that it is not needed and therefore it is
>> clumsy and inelegant to check. I had searched in the docs but have not found
>> anything
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Kostya Vasilyev]

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:

data.intent.setExtrasClassLoader(cl);

This code will crash inside the framework if the intent is null.

However, this is a specific version of *stock* Android... Other
versions, including manufacturer specific or custom ROMs may, in
theory, be different.

Weird things do happen though, when you have an app in Play and it
gets installed on a fair number of different devices. I recall one
crash report in Play where the framework was complaining about not
being able to find the application's .apk while instantiating the
Application subclass object (or something equally absurd). Over time,
you learn to not worry about these too much.

-- K

2013/7/15 Palmer Eldritch :
> 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
>
> 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
>
> Even in one of the most fundamental callbacks
>
> Maybe have a look at my links after all ?
>
>
> 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(); // can intent==null here
>> ?
>> }
>>
>> I need to solve this once and for all so please no ifs and buts. I would
>> check for null but I suspect that it is not needed and therefore it is
>> clumsy and inelegant to check. I had searched in the docs but have not found
>> anything
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Palmer Eldritch]

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

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

Even in one of the most fundamental callbacks

Maybe have a look at my links after all ?

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(); // can intent==null here 
> ?
> }
>
> I need to solve this once and for all so please no ifs and buts. I would 
> check for null but I suspect that it is not needed and therefore it is 
> clumsy and inelegant to check. I had searched in the docs but have not 
> found anything
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[TreKing]

On Sun, Jul 14, 2013 at 2:02 AM, Piren  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 (intent == null) because it's
"clumsy" if unnecessary.

-
TreKing  - Chicago
transit tracking app for Android-powered devices

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Piren]

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 cares how ReceiverData is made? 
the code that uses it will throw an exception if the Intent part is null.

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? What promises 
you that Math.Min will always return the minimal value, or any value for 
that matter? How do you know that Activity.onCreate will get called with an 
Intent?




On Thursday, July 11, 2013 7:41:49 PM UTC+3, Palmer Eldritch wrote:
>
> 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 : 
> http://grepcode.com/search?query=ReceiverData&n=
>
> compare : 
> http://androidxref.com/4.2.2_r1/search?q=ReceiverData&defs=&refs=&path=&hist=&project=abi&project=bionic&project=bootable&project=build&project=cts&project=dalvik&project=development&project=device&project=docs&project=external&project=frameworks&project=gdk&project=hardware&project=libcore&project=libnativehelper&project=ndk&project=packages&project=pdk&project=prebuilts&project=sdk&project=system
>
> In froyo the intent is just passed in :
>
>
> http://androidxref.com/2.2.3/xref/frameworks/base/core/java/android/app/ActivityThread.java#1563
>
> In 4.2.2 we have the same in a constructor : 
> http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ActivityThread.java#648
>
> Now scheduleReceiver we have in ApplicationThreadNative : 
> http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ApplicationThreadNative.java#758
>  and in ActivityThread : 
> http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ActivityThread.java#645
>
> What's the difference ?
>
> Anyway in ApplicationThreadNative it is called here 
> http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ApplicationThreadNative.java#197and
>  it is passed an intent from : 
>
>
> http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ApplicationThreadNative.java#189
>
> So Intent intent = Intent.CREATOR.createFromParcel(data);
>
> but this is where I give up - where is this "data" (a Parcel instance) 
> created ?
>
>
>
>
>
>
> On Thursday, July 11, 2013 5:54:07 PM UTC+3, Piren wrote:
>>
>> 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 get a null intent. feel free to verify this is true for all previous 
>> versions as well (and don't forget to keep checking this method every time 
>> they make a new build).
>>
>> http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/app/ActivityThread.java#2335
>>
>>
>> On Thursday, July 11, 2013 4:09:27 PM UTC+3, Palmer Eldritch wrote:
>>>
>>> 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 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 learned it's 
 always a good idea to check for nulls when you're supposed to receive an 
 object.

 On Thursday, July 11, 2013 6:01:13 AM UTC+3, Palmer Eldritch wrote:
>
> 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 4:18:09 AM UTC+3, TreKing wrote:
>>
>>
>> On Wed, Jul 10, 2013 at 4:14 PM, Palmer Eldritch 
>> 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 get a 
>> null 
>> pointer exception from here, you know i

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Palmer Eldritch]

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 : 
http://grepcode.com/search?query=ReceiverData&n=

compare : 
http://androidxref.com/4.2.2_r1/search?q=ReceiverData&defs=&refs=&path=&hist=&project=abi&project=bionic&project=bootable&project=build&project=cts&project=dalvik&project=development&project=device&project=docs&project=external&project=frameworks&project=gdk&project=hardware&project=libcore&project=libnativehelper&project=ndk&project=packages&project=pdk&project=prebuilts&project=sdk&project=system

In froyo the intent is just passed in :

http://androidxref.com/2.2.3/xref/frameworks/base/core/java/android/app/ActivityThread.java#1563

In 4.2.2 we have the same in a constructor : 
http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ActivityThread.java#648

Now scheduleReceiver we have in ApplicationThreadNative : 
http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ApplicationThreadNative.java#758
 and in ActivityThread : 
http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ActivityThread.java#645

What's the difference ?

Anyway in ApplicationThreadNative it is called here 
http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ApplicationThreadNative.java#197
 
and it is passed an intent from : 

http://androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/ApplicationThreadNative.java#189

So Intent intent = Intent.CREATOR.createFromParcel(data);

but this is where I give up - where is this "data" (a Parcel instance) 
created ?






On Thursday, July 11, 2013 5:54:07 PM UTC+3, Piren wrote:
>
> 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 
> get a null intent. feel free to verify this is true for all previous 
> versions as well (and don't forget to keep checking this method every time 
> they make a new build).
>
> http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/app/ActivityThread.java#2335
>
>
> On Thursday, July 11, 2013 4:09:27 PM UTC+3, Palmer Eldritch wrote:
>>
>> 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 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 learned it's 
>>> always a good idea to check for nulls when you're supposed to receive an 
>>> object.
>>>
>>> On Thursday, July 11, 2013 6:01:13 AM UTC+3, Palmer Eldritch wrote:

 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 4:18:09 AM UTC+3, TreKing wrote:
>
>
> On Wed, Jul 10, 2013 at 4:14 PM, Palmer Eldritch 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 get a null 
> pointer exception from here, you know it can be null.
>
> You're welcome.
>
>
> -
> TreKing  - 
> Chicago transit tracking app for Android-powered devices
>  


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more option

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Piren]

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 
get a null intent. feel free to verify this is true for all previous 
versions as well (and don't forget to keep checking this method every time 
they make a new build).
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/app/ActivityThread.java#2335


On Thursday, July 11, 2013 4:09:27 PM UTC+3, Palmer Eldritch wrote:
>
> 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 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 learned it's 
>> always a good idea to check for nulls when you're supposed to receive an 
>> object.
>>
>> On Thursday, July 11, 2013 6:01:13 AM UTC+3, Palmer Eldritch wrote:
>>>
>>> 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 4:18:09 AM UTC+3, TreKing wrote:


 On Wed, Jul 10, 2013 at 4:14 PM, Palmer Eldritch 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 get a null 
 pointer exception from here, you know it can be null.

 You're welcome.


 -
 TreKing  - Chicago 
 transit tracking app for Android-powered devices
  
>>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Palmer Eldritch]

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 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 learned it's 
> always a good idea to check for nulls when you're supposed to receive an 
> object.
>
> On Thursday, July 11, 2013 6:01:13 AM UTC+3, Palmer Eldritch wrote:
>>
>> 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 4:18:09 AM UTC+3, TreKing wrote:
>>>
>>>
>>> On Wed, Jul 10, 2013 at 4:14 PM, Palmer Eldritch 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 get a null 
>>> pointer exception from here, you know it can be null.
>>>
>>> You're welcome.
>>>
>>>
>>> -
>>> TreKing  - Chicago 
>>> transit tracking app for Android-powered devices
>>>  
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Piren]

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 learned it's 
always a good idea to check for nulls when you're supposed to receive an 
object.

On Thursday, July 11, 2013 6:01:13 AM UTC+3, Palmer Eldritch wrote:
>
> 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 4:18:09 AM UTC+3, TreKing wrote:
>>
>>
>> On Wed, Jul 10, 2013 at 4:14 PM, Palmer Eldritch 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 get a null 
>> pointer exception from here, you know it can be null.
>>
>> You're welcome.
>>
>>
>> -
>> TreKing  - Chicago 
>> transit tracking app for Android-powered devices
>>  
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Palmer Eldritch]

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 4:18:09 AM UTC+3, TreKing wrote:
>
>
> On Wed, Jul 10, 2013 at 4:14 PM, Palmer Eldritch 
> 
> > 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 get a null 
> pointer exception from here, you know it can be null.
>
> You're welcome.
>
>
> -
> TreKing  - Chicago 
> transit tracking app for Android-powered devices
>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[TreKing]

On Wed, Jul 10, 2013 at 4:14 PM, Palmer Eldritch  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 get a null pointer
exception from here, you know it can be null.

You're welcome.

-
TreKing  - Chicago
transit tracking app for Android-powered devices

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?

[Palmer Eldritch]

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(); // can intent==null here 
> ?
> }
>
> I need to solve this once and for all so please no ifs and buts. I would 
> check for null but I suspect that it is not needed and therefore it is 
> clumsy and inelegant to check. I had searched in the docs but have not 
> found anything
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.