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 <[email protected]<javascript:>>
> wrote:
> >
> > On Sun, Jul 14, 2013 at 10:08 PM, Kristopher Micinski
> > <[email protected] <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
> > [email protected]<javascript:>
> > To unsubscribe from this group, send email to
> > [email protected] <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 [email protected] <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 [email protected]
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.