Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?
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 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 http://sites.google.com/site/rezmobileapps/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?
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 treki...@gmail.comjavascript:
wrote:
On Sun, Jul 14, 2013 at 10:08 PM, Kristopher Micinski
krismi...@gmail.com javascript: 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.comjavascript:
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com javascript:
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 javascript:.
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?
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 treking...@gmail.com wrote:
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.
--
--
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 http://sites.google.com/site/rezmobileapps/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?
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 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.
Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?
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 gpi...@gmail.com javascript: 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
Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?
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 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?
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=ReceiverDatan= compare : http://androidxref.com/4.2.2_r1/search?q=ReceiverDatadefs=refs=path=hist=project=abiproject=bionicproject=bootableproject=buildproject=ctsproject=dalvikproject=developmentproject=deviceproject=docsproject=externalproject=frameworksproject=gdkproject=hardwareproject=libcoreproject=libnativehelperproject=ndkproject=packagesproject=pdkproject=prebuiltsproject=sdkproject=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 the@gmail.comwrote: 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 http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- -- You received this message
Re: [android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?
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 (intent == null) because it's clumsy if unnecessary. - TreKing http://sites.google.com/site/rezmobileapps/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?
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 the.u...@gmail.com:
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?
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 the.u...@gmail.com 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?
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 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 http://sites.google.com/site/rezmobileapps/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?
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 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?
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 http://sites.google.com/site/rezmobileapps/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?
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 treking...@gmail.com wrote:
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.
--
--
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?
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 the@gmail.comwrote: 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 http://sites.google.com/site/rezmobileapps/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?
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 the@gmail.comwrote: 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 http://sites.google.com/site/rezmobileapps/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?
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 the@gmail.comwrote: 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 http://sites.google.com/site/rezmobileapps/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?
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=ReceiverDatan= compare : http://androidxref.com/4.2.2_r1/search?q=ReceiverDatadefs=refs=path=hist=project=abiproject=bionicproject=bootableproject=buildproject=ctsproject=dalvikproject=developmentproject=deviceproject=docsproject=externalproject=frameworksproject=gdkproject=hardwareproject=libcoreproject=libnativehelperproject=ndkproject=packagesproject=pdkproject=prebuiltsproject=sdkproject=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 the@gmail.comwrote: 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 http://sites.google.com/site/rezmobileapps/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?
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 get a null pointer exception from here, you know it can be null. You're welcome. - TreKing http://sites.google.com/site/rezmobileapps/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?
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 the@gmail.comjavascript: 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 http://sites.google.com/site/rezmobileapps/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.
