CTS can launch automatically On Aug 28, 2013 10:22 AM, "Tai Nguyen (tainguye)" <[email protected]> wrote:
> > > On 8/28/13 9:00 AM, "Stephen Smalley" <[email protected]> wrote: > > >On 08/27/2013 02:12 PM, Tai Nguyen (tainguye) wrote: > >> All, > >> > >> We are looking for recommendation to support incremental automation > >>test for SEAndroid device. Since it is expected that developers will add > >>automation tests and those tests are run automatically on the device for > >>every build, having the policies to support those unknown test programs > >>is a challenge. > >> > >> I think SEAndroid can handle test apk pretty well However, we are not > >>sure about native (Linux) test programs. It seems that we may need to > >>add rules to transition these test programs to right domain. So, it > >>seems that the whole development team need to create rules for test > >>programs. This is not desirable because these test rules may end up in > >>release/official loads. In addition, the team may not have SEAndroid > >>knowledge to create right rules. > >> > >> We really appreciate if you can provide us your feedback or > >>recommendation. > > > >When you say "native (Linux) test programs", do you mean: > >a) such programs executed from a regular (unprivileged) adb shell, > >b) such programs executed from an adb shell after an adb root or via su, > >c) such programs executed from an app > > Since the goal is to run the tests automatically after a build is > complete, we use ssh to get a shell on the device (i.e., no human > interaction). > The shell can be privilege on non privilege based on login. Then the tests > are executed from the shell. > > > > > >Do the test programs do things that you don't want to permit on > >production devices? Or are they testing functionality that should in > >fact work on production devices? > > Because the goal is to test the code on the device, not the test code, we > don't need to restrict access to test code. Similarly, the test code goal > is to test the production code in production devices, so the work should > be done by the production code and not the test code. In other words, the > test code setup the test scenario then trigger the production code to run > in that environment. > We think that we can put test program in no-constraint group, however, it > is unclear how do we transition those programs into that domain given that > we don't want to pollute policy with these test program rules. We have > different and independent development team working on the device, and most > of the team do not have knowledge of SELinux policy, so it is undesirable > to ask each team to write policy for their test case. Also, it is also > undesirable to write too many rules for test programs. > > Let me share some background information as well > > We have different category of automation test (e.g., unit test, component > test, integration test). Low level tests (unit test, component test) can > be done offline (i.e., not on device). High level tests (e.g., integration > test) are done on the device but should not use mock or stub object. So, > the tests in this discussion are high level tests. > > > > -- > This message was distributed to subscribers of the seandroid-list mailing > list. > If you no longer wish to subscribe, send mail to [email protected] > the words "unsubscribe seandroid-list" without quotes as the message. >
