Thanks Milosz and Neil for the feedback.

The reason I brought this up was , Tradefed provides some inbuilt tools(logging, log analyzer etc) for Android that need to be taken care by the test developer.

I think the best way to use Tradefed would be inside LXC in V2 as you suggested.

Some investigation is needed onre how best Tradefed can be used along with lava test case. There is the only overlap i see.

Once I migrate to V2, I will investigate this further at my end.

Thanks

Sandeep

On Wed, Aug 24, 2016 at 3:17 AM, Milosz Wasilewski <milosz.wasilewski@linaro.org> wrote:

Sandeep,

On 23 August 2016 at 18:40, Sandeep Chawla <sandeep@cyngn.com> wrote:
> Hello,
>
> Google has release the latest version of Tradefed with the Android N
> release.
>
> https://source.android.com/devices/tech/test_infra/tradefed/index.html
>
> Lots of dispatcher/slave features which LAVA already supports.
>

Thanks for pointing this out. I'll take a look.

> Given this update, is LAVA exploring to adopt the new mechanism or continue
> developing its own architecture ?

I'm not sure there is overlap. Main purpose of LAVA is to provision
the target device with your OS build. Tradefed doesn't have this
implemented [1]. Testing comes later. We're already using tradefed for
running CTS tests. If more can be done using similar means, that's
great.

[1] Quote from the docs:
"The OEM could implement a device flashing module that will execute
during the Target Setup stage of the lifecycle. That module would have
complete control over the device during its execution period, which
would allow it to potentially force the device into the bootloader,
flash, and then force the device to reboot back into userspace mode."

milosz