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.
[android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?
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.
[android-developers] Re: Vertical Datepicker
Just in case if someone is facing the same problem, here's the solution: The datePicker basic layout is LinearLayout, so it's pretty simple to get it with getChildAt(int position) and change it's orientation to vertical. This made the trick for me. The other big problem about this datePicker is changing it's divider colors - it's NumberPicker divider color and it's CalendarView divider color. Changing the divider color and the related colors of CalendarView is pretty simple(it's done by changing the appropriate style items), but the dividers of the NumberPickers are kind of big problem. The real issue is that the field for changing the divider's drawable is a private one by default. So I managed to find some workarounds to this problem: 1. Use NP widget NumberPicker 2. Use Reflection to access the field mSelectionDivider and change it's value. I hope these workarounds will help someone :) -- -- 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] about WifiDisplayController's connect function
dear all:
i'm seeing wifi display source code and wondering
why using !mDesiredDevice.deviceAddress.equals(device.deviceAddress) and
!mConnectedDevice.deviceAddress.equals(device.deviceAddress) to test?
meaning not equal??
plz help!
-
private void connect(final WifiP2pDevice device) {
if (mDesiredDevice != null
!mDesiredDevice.deviceAddress.equals(device.deviceAddress)) {
if (DEBUG) {
Slog.d(TAG, connect: nothing to do, already connecting to
+ describeWifiP2pDevice(device));
}
return;
}
if (mConnectedDevice != null
!mConnectedDevice.deviceAddress.equals(device.deviceAddress)
mDesiredDevice == null) {
if (DEBUG) {
Slog.d(TAG, connect: nothing to do, already connected to
+ describeWifiP2pDevice(device) + and not part
way through
+ connecting to a different device.);
}
return;
}
...
}
--
--
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.
[android-developers] Re: can _ever_ the intent received by a BroadcastReceiver onReceive() method be null?
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?
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.
[android-developers] Google Play services lib crashing with: java.lang.ClassCastException: com.google.android.gms.common.images.e cannot be cast to android.content.ComponentCallbacks
HELP: we are getting this error in large numbers from customers since releasing an update which adds Google Play services achievements to our game. Any ideas would be very appreciated. This error crashes the app. There are minor variations in the stack traces but they are all a android.gms.common.images.e cannot be cast to android.content.ComponentCallbacks exception. The most common trace starts from android.app.Application.onConfigurationChanged(), we also get some from android.app.Application.onLowMemory(). Both those are methods in the Interface http://developer.android.com/reference/android/content/ComponentCallbacks.html . I'm not sure what's happening but one guess is that Google Play services is registering an instance of com.google.android.gms.common.images.e (whatever that is) as if it is a ComponentCallbacks, then when the OS calls a method on that instance the class cast exception is triggered. The crash seems to occur when the app has just been paused, or has not been active for some time; these may be the first times any method in ComponentCallbacks is called. We use android.gms.common.images.ImageManager to load achievement images in our app; it's the same package, so possibly related (then again, maybe not :) 4.1.2 stack trace: 21:02:00.411 Exception main: java.lang.ClassCastException: com.google.android.gms.common.images.e cannot be cast to android.content.ComponentCallbacks android.app.Application.onConfigurationChanged(Application.java:99) hm java.lang.ClassCastException: com.google.android.gms.common.images.e cannot be cast to android.content.ComponentCallbacks at android.app.Application.onConfigurationChanged(Application.java:99) at android.app.ActivityThread.performConfigurationChanged(ActivityThread.java:3653) at android.app.ActivityThread.handleConfigurationChanged(ActivityThread.java:3792) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1337) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:137) at android.app.ActivityThread.main(ActivityThread.java:4918) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:511) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1004) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:771) at dalvik.system.NativeStart.main(Native Method) 4.0.4 stack trace: 21:18:37.459 Exception main: java.lang.ClassCastException: com.google.android.gms.common.images.e cannot be cast to android.content.ComponentCallbacks android.app.Application.onConfigurationChanged(Application.java:90) hm java.lang.ClassCastException: com.google.android.gms.common.images.e cannot be cast to android.content.ComponentCallbacks at android.app.Application.onConfigurationChanged(Application.java:90) at android.app.ActivityThread.performConfigurationChanged(ActivityThread.java:3461) at android.app.ActivityThread.handleConfigurationChanged(ActivityThread.java:3585) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1220) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:137) at android.app.ActivityThread.main(ActivityThread.java:4424) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:511) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551) at dalvik.system.NativeStart.main(Native Method) The onLowMemory() variation: 18:00:46.230 Exception main: java.lang.ClassCastException: com.google.android.gms.common.images.e cannot be cast to android.content.ComponentCallbacks android.app.Application.onLowMemory(Application.java:99) hm java.lang.ClassCastException: com.google.android.gms.common.images.e cannot be cast to android.content.ComponentCallbacks at android.app.Application.onLowMemory(Application.java:99) at android.app.ActivityThread.handleLowMemory(ActivityThread.java:3690) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1233) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:137) at android.app.ActivityThread.main(ActivityThread.java:4424) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:511) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551) at dalvik.system.NativeStart.main(Native Method) -- -- 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
[android-developers] Required: Oracle PL/SQL Developer at TX
Hi, Please let me know if you have someone available for below mention requirement. Send resumes to m...@tekenergyusa.com Position: Oracle Developer Location: Irving, TX Duration: 6+ Months Interview process: Phone then face to face interview Oracle Developer with CRM experience Knowledge on testing is must Mark TekEnergy 214-230-0925 -- -- 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: Seekbar Save state and restore
I am trying to save the actual position of 200 seekbars on one activity. I
think this means i have to save/restore the position of the seekbars and
the integer value of the seekbar before the activity was paused? i had read
the API and it made no reference to seekbars . I was not aware they were
widgets nor that i could store their positions and int value in shared
preferences or that shared preferences even existed. Thank you Fred for
that. What would be the correct way to accomplish the above TreKing?
Thank you both for your time and efforts
On Thursday, July 11, 2013 10:14:38 PM UTC-4, Keith Zettler wrote:
How exactly can i save/restore this seekbar if user uses back button or
activity is destyroyed?
I have not been able to find a specific example anywhere
public class MainActivity extends Activity implements
SeekBar.OnSeekBarChangeListener {
SeekBar seekBar;
SeekBar seekBar1;
TextView textView;
TextView textView1;
TextView textView2;
TextView textView3;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
seekBar=(SeekBar)findViewById(R.id.seekbar);
seekBar1=(SeekBar)findViewById(R.id.seekBar1);
textView=(TextView)findViewById(R.id.textview);
textView1=(TextView)findViewById(R.id.textView1);
textView2=(TextView)findViewById(R.id.textView2);
textView3=(TextView)findViewById(R.id.textView3);
seekBar.setOnSeekBarChangeListener(this);
}
@Override
public void onProgressChanged(SeekBar seekBar, int progress,
boolean fromUser) {
// Notify that the progress level has changed.
int A= (progress+250);
textView.setText(SeekBar now at the value of:+progress);
textView1.setText(SeekBar now at the value of:+A);
}
@Override
public void onStartTrackingTouch(SeekBar seekBar) {
// Notify that the user has started a touch gesture.
//textView.setText(textView.getText()+\n+SeekBar Touch
Started);
}
@Override
public void onStopTrackingTouch(SeekBar seekBar) {
// Notify that the user has finished a touch gesture.
// textView.setText(textView.getText()+\n+SeekBar Touch
Stopped);
}
@Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is
present.
getMenuInflater().inflate(R.menu.main, menu);
return true;
}
}
--
--
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] Issue with SQLiteOpenHelper on android 2.X and 3.X
Maybe this SO-thread helps:
http://stackoverflow.com/questions/7647524/android-failed-to-setlocale-when-constructing-closing-the-database
On Mon, Jul 15, 2013 at 9:08 AM, Zoheb Rahman zoh...@gmail.com wrote:
So i made a big mistake of testing my code on android 4.0 + and thinking it
would work fine on other versions. But i am facing issues with 2.X and 3.X
with SQLiteOpenHelper.
First the code :
public class HelperDB extends SQLiteOpenHelper implements BaseColumns {
public static final int DATABASE_VERSION = 2;
public static final String DATABASE_NAME = MYDB.db;
public static final String TABLE_NAME = MYtable;
public static final String TABLE_NAME_LOGO = MYLogos;
public static final String COLUMN_NAME_1 = x;
public static final String COLUMN_NAME_2 = ;
public static final String COLUMN_NAME_3 = ;
public static final String COLUMN_NAME_4 = ;
public static final String COLUMN_NAME_LOGO = logo;
public static final String COLUMN_NAME_5 = ;
public static final String COLUMN_NAME_6 = f;
public static final String COLUMN_NAME_7= Abc;
public HelperDB(Context context)
{
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
@Override
public void onCreate(SQLiteDatabase db){
db.execSQL(CREATE TABLE + TABLE_NAME + ( + _ID + INTEGER PRIMARY
KEY autoincrement, + COLUMN_NAME_1 + TEXT not null, + COLUMN_NAME_2
+ TEXT not null, + COLUMN_NAME_3 + TEXT not null, +
COLUMN_NAME_4 + LONG not null, + COLUMN_NAME_5 + INT DEFAULT 99, +
COLUMN_NAME_6 + INT DEFAULT 99););
db.execSQL(CREATE TABLE + TABLE_NAME_LOGO + ( + _ID + INTEGER
PRIMARY KEY autoincrement, + COLUMN_NAME_6 + TEXT not null, +
COLUMN_NAME_7 + INTERGET not null););
}
@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion)
{
}
}
**
public class MatchesDB {
private HelperDB dbHelper;
private SQLiteDatabase dbw, dbr;
public static int id;
public MatchesDB(Context context){
dbHelper = new HelperDB(context);
dbw = dbHelper.getWritableDatabase();
dbr = dbHelper.getReadableDatabase();
}
public void fillinfotable(){}
And all other functions to query the database and delete etc
Creating the DB by calling
MatchesDB newdb = new MatchesDB(context);
newdb.fillinfotable();
All this is working perfectly on all 4.0 + devices. However i'm getting the
following error when trying to run on 2.x devices
07-14 21:29:14.890: E/Database(22231): CREATE TABLE android_metadata failed
07-14 21:29:14.898: E/Database(22231): CREATE TABLE android_metadata failed
07-14 21:29:15.640: E/Database(22231): Failed to setLocale() when
constructing, closing the database
07-14 21:29:15.640: E/Database(22231):
android.database.sqlite.SQLiteException: database is locked
07-14 21:29:15.640: E/Database(22231): at
android.database.sqlite.SQLiteDatabase.native_setLocale(Native Method)
07-14 21:29:15.640: E/Database(22231): at
android.database.sqlite.SQLiteDatabase.setLocale(SQLiteDatabase.java:2000)
07-14 21:29:15.640: E/Database(22231): at
android.database.sqlite.SQLiteDatabase. init(SQLiteDatabase.java:1857)
07-14 21:29:15.640: E/Database(22231): at
android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:822)
07-14 21:29:15.640: E/Database(22231): at
android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:856)
07-14 21:29:15.640: E/Database(22231): at
android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:849)
07-14 21:29:15.640: E/Database(22231): at
android.app.ContextImpl.openOrCreateDatabase(ContextImpl.java:556)
07-14 21:29:15.640: E/Database(22231): at
android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:203)
07-14 21:29:15.640: E/Database(22231): at
android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:118)
Any help is Highly appreciated !! really want a quick fix as the app is
already on the play store and i need to publish an update.
I have followed the developers guide on the android website and have been
searching for a solution and just cant seem to find anything anywhere
--
--
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.
--
Michael
Re: [android-developers] about WifiDisplayController's connect function
Really?
Doesn't the debug output pretty much sum it up? The code ensure that
the wifi being connected to isn't the same as the one currently
connected to...
On Mon, Jul 15, 2013 at 10:53 AM, Baodong Chen chenbdche...@gmail.com wrote:
dear all:
i'm seeing wifi display source code and wondering
why using !mDesiredDevice.deviceAddress.equals(device.deviceAddress) and
!mConnectedDevice.deviceAddress.equals(device.deviceAddress) to test?
meaning not equal??
plz help!
-
private void connect(final WifiP2pDevice device) {
if (mDesiredDevice != null
!mDesiredDevice.deviceAddress.equals(device.deviceAddress)) {
if (DEBUG) {
Slog.d(TAG, connect: nothing to do, already connecting to
+ describeWifiP2pDevice(device));
}
return;
}
if (mConnectedDevice != null
!mConnectedDevice.deviceAddress.equals(device.deviceAddress)
mDesiredDevice == null) {
if (DEBUG) {
Slog.d(TAG, connect: nothing to do, already connected to
+ describeWifiP2pDevice(device) + and not part way
through
+ connecting to a different device.);
}
return;
}
...
}
--
--
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.
--
Michael Banzon
http://michaelbanzon.com/
--
--
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: Seekbar Save state and restore
On Mon, Jul 15, 2013 at 9:45 PM, Keith Zettler leftcont...@gmail.comwrote: I am trying to save the actual position of 200 seekbars on one activity. Two *hundred*? In *one* activity? Jesus. That does not seem right ... but hey, it's your app. I think this means i have to save/restore the position of the seekbars and the integer value of the seekbar Yes... before the activity was paused? No. *After*. See the activity lifecyle: http://developer.android.com/guide/components/activities.html#Lifecycle Pay special attention to the part about saving state. i had read the API and it made no reference to seekbars . You're quite hung up on these Seekbars. Again, these are just another widget like any other - there's nothing special about them that would require special mention of how to handle saving and restoring their state. What would be the correct way to accomplish the above TreKing? Read the links I gave you, then implement the correct methods to save and restore (onSaveInstanceState, onRestoreInstanceState, respectively) the states of your seekbars. - 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.
