Hi all!
This is very good analysis you have done, and I would just add that Monkey
is only one simpler example where the test execution using abrek is not an
option. Another example from Android world is CTS:
http://source.android.com/compatibility/cts-intro.html. Most certainly, all
test suites
2011/2/16 Mirsad Vojnikovic mirsad.vojniko...@linaro.org:
Hi all!
hi Mirsad,
This is very good analysis you have done, and I would just add that Monkey
is only one simpler example where the test execution using abrek is not an
option.
True.
Another example from Android world is CTS:
W dniu 16.02.2011 15:10, Paul Larson pisze:
Another crazy option would be to expose LAVA Job Dispatcher
directly and allow people to run jobs. In this case one job
I hope you don't really think this is a crazy idea, because it's
*exactly* what we discussed doing, and I think
On 16 February 2011 06:10, Paul Larson paul.lar...@linaro.org wrote:
Another crazy option would be to expose LAVA Job Dispatcher directly and
allow people to run jobs. In this case one job would use abrek and some
other tools to invoke tests, process results and send them to the dashboard
On 16 February 2011 06:24, Paul Larson paul.lar...@linaro.org wrote:
On Wed, Feb 16, 2011 at 8:16 AM, Zygmunt Krynicki
zygmunt.kryni...@linaro.org wrote:
Yeah, when you mentioned this now I started thinking. Do we really need a
daemon-like component for the dispatcher in general or just
Hello list,
Regarding integration of LAVA [1] architecture with Android devices,
we would like to reuse the existing
infrastructure and framework design. Abrek [2] is a great testsuite
framework for running test cases and
benchmarks. However, due to the restrictions of unusual Android
runtime,
W dniu 15.02.2011 21:01, Jim Huang pisze:
Hi Jim, great work!
** Why can't we execute LAVA/Abrek directly on Android devices?
I agree that direct abrek is not the right solution for Android. I think
there is a class of use cases that also falls into this category:
* testing early silicon
