Yes and no -- it looks like a deliberate change, but it wasn't the original intention of the test -- the test was put in place as part of https://issues.apache.org/jira/browse/CB-6428, and it originally tested that it could copy just the file plugin's assets into local storage.
CB-6428 is about being able to read from android_assets, and so any directory within the app assets would do. I suspect that the file plugin's dir was chosen because it should exist if we're testing it. The source directory was changed, though, about two weeks ago, with this commit: https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c (no JIRA issue, but the comments is that it fixes an issue when browserify is used -- I presume that the JS-concatenation means that the plugin JS files aren't present anymore.) So, any directory under /android_assets/ will do, but you should make sure that your patch doesn't fail in the same way as the original if browserify is being used. On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) < [email protected]> wrote: > Hi guys. > > It looks like "file.spec.144 copyTo: asset directory" tries to copy whole > www directory. Was it done intentionally? > On slow environments, especially emulators this can take huge amount of > time (up to 5 minutes). > > In case it is not substantial and any folder will do, I've prepared a fix > for this test to stop timing out on Android emulators: > https://github.com/apache/cordova-plugin-file/pull/129 > > Thanks, > Alexander Sorokin >
