Permissions in instrumentation test apps

[Adam Vollmer]

I'm trying to set up instrumentation tests in my application to verify the behavior of content within, but I'm having trouble running some of them due to the autogenerated manifest.

The problem is that I've got code from a 3rd party that performs network activities as part of its functionality, and I can't test important parts without that functionality working. It's not feasible for me to mock the responses/infrastructure, so that's not a reasonable solution.

Unfortunately, the autogenerated manifest for the instrumentation tests does not contain any permissions, except for potentially READ/WRITE external storage. I'm also unable to override the autogenerated manifest with one I've created, and the manifest doesn't appear to inherit any permissions.

What I'm wondering is whether there's a way I can move forward in testing the code around this component, or whether I'll need to put that coverage aside for now until a later change is made that allows me to test this?

[Xavier Ducrohet]

Shouldn't the tested app have the internet permission?

We could certainly look at having the ability to provide a manifest mostly to add extra stuff (we would still generate the base manifest to get the proper package, and instrumentation nodes).

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Adam Vollmer]

There's actually no separate app under test for this; this is an instrumentation test of a library, so only the test apk is generated to run.

Is it not expected to perform instrumentation tests of only certain libraries? Would I have to actually create an application for the library just to "test" it with the appropriate permissions?

[Xavier Ducrohet]

the manifest of the library should be merged in the test app in this case. So if your library does network stuff and requires the internet permission, the tested app should get the same permission.

Is it not the case?

[Adam Vollmer]

It... is now.

I apologize, I must have made a mistake somewhere and not realized, as my test apks were definitely not getting the right permissions previously, but the permissions are actually being reflected now as requested.

Thanks anyway!

[Adam Vollmer]

Just to follow up on this, I've found a convenient use case for having additional manifest content for testing.

I'm testing an audio service, and during testing I don't want to actually play snippets of audio through the speakers. As such, I'd like to get the permission to modify the stream volume and mute the device before testing. Right now, I'm adding that permission to the library's manifest, even though I won't be using it in the final product. Once I'm able to additively place content into test manifests, I'll be placing it there instead.

[Xavier Ducrohet]

Right now based on how the libraries work, you could add that extra permission to src/debug/AndroidManifest.xml. This will impact the library only when build during debug, which is used for testing (and nothing else), and won't impact your release packaging which is what gets used by other projects.

When we do allow other projects to use the debug version of a library this won't work as well (though you are unlikely to ever ship the debug version anyway so it could still work).

[Jake Wharton]

We could certainly look at having the ability to provide a manifest mostly to add extra stuff (we would still generate the base manifest to get the proper package, and instrumentation nodes).

Extra arbitrary permissions can be useful. For our Maven setup we add the ability to unlock and hold a wake lock so the device display is on and unlocked. Not only is it pretty, but ddmlib-based screenshots come back blank without it.

[Adam Vollmer]

Thanks Xavier, I'll give that a try as an interim workaround.

On Fri, Jul 19, 2013 at 2:11 AM, Jake Wharton <jakew...@gmail.com> wrote:

We could certainly look at having the ability to provide a manifest mostly to add extra stuff (we would still generate the base manifest to get the proper package, and instrumentation nodes).

Extra arbitrary permissions can be useful. For our Maven setup we add the ability to unlock and hold a wake lock so the device display is on and unlocked. Not only is it pretty, but ddmlib-based screenshots come back blank without it.

--

[Xavier Ducrohet]

Makes sense.

https://code.google.com/p/android/issues/detail?id=57819

On Thu, Jul 18, 2013 at 11:11 PM, Jake Wharton <jakew...@gmail.com> wrote:

We could certainly look at having the ability to provide a manifest mostly to add extra stuff (we would still generate the base manifest to get the proper package, and instrumentation nodes).

Extra arbitrary permissions can be useful. For our Maven setup we add the ability to unlock and hold a wake lock so the device display is on and unlocked. Not only is it pretty, but ddmlib-based screenshots come back blank without it.

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Diego Garcia]

Sorry to hijack this thread, but I started another with a related issue and got no attention:

https://groups.google.com/forum/#!topic/adt-dev/kxGB6odcidQ

Basically, I have an library that provides a Fragment, so my instrumentation creates a test Activity to try it out.  Since that activity needs to be in the instrumentation manifest, my specs are failing.  I'll try adding the activity to the debug manifest as suggested.

[Xavier Ducrohet]

Yes, that's another good reason to have the ability to provide a custom manifest for the test.

I talked with the engineer who did the current manifest and we came to the conclusion that we need to revise our merging strategy when it comes to the main manifest and the overlay manifest (build type, flavors) and the dependencies (library projects), as the merge should behave slightly differently in both cases. I think when we revisit this we'll look at merging the test manifest and we'll see what behavior we want there.

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Diego Garcia]

For anyone interested: placing the manifest under debug works, for my case.