New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 617734 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Tests should not set DIR_ANDROID_APP_DATA to be the same as DIR_SOURCE_ROOT

Project Member Reported by agrieve@chromium.org, Jun 6 2016

Issue description

DIR_SOURCE_ROOT is /sdcard/chromium_tests_root, and it's where the test runner pushes side-loaded test files.

Currently, tests also set DIR_ANDROID_APP_DATA to be /sdcard/chromium_tests_root.

My guess as to the reason for this: .pak files used to be extracted on start-up to the private data directory. Using DIR_ANDROID_APP_DATA and pointing it to the side-loaded data files (where .pak files were side-loaded) was a convenient way to have the same .pak file found by both tests and at runtime.

Why should we separate these two things?
Side-loaded test data and private app data serve two separate purposes, and pointing them to the same place can have surprising consequences. E.g. you may want to clear all app data between tests.

 
The only pak files that are still extracted on start-up are locale pak files, and I don't think tests use these (at least not many).

So, I think the "fix" here, is to either bundle the .pak files in the test apks, or to change the loading logic for them to look for them within the DIR_SOURCE_ROOT rather than DIR_ANDROID_APP_DATA. Then, we can stop overriding DIR_ANDROID_APP_DATA in tests.
Note that the loading logic is app code, not test code. I don't think we can use DIR_SOURCE_ROOT there.
... and so I'm not sure either of those are viable solutions.
Most spots that load these things on android (icudata, pak files), first try and load them from the .apk, then fall-back to loading from DIR_ANDROID_APP_DATA. The fallback is there only for tests. Since it's only for tests already, we could change it.

If we moved to loading directly from the .apk, then I'm hoping the normal non-fallback loading code will "just work", and we can remove the fall-back only-for-tests code.

Ah, I didn't realize that was fallback code only there for tests. sgtm
Project Member

Comment 6 by bugdroid1@chromium.org, Feb 7 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d5ae68ebcd7cc869074e033de066d7f769477f16

commit d5ae68ebcd7cc869074e033de066d7f769477f16
Author: Sergey Ulanov <sergeyu@chromium.org>
Date: Wed Feb 07 20:14:21 2018

Add DIR_ASSETS in PathService.

Currently DIR_MODULE is used when loading assets such as ICU data or .pak
files. On some platforms these files are stored in a separate directory.
Fuchsia solves this problem with DIR_FUCHSIA_RESOURCE. Android uses
DIR_ANDROID_APP_DATA in tests. This approach doesn't scale well because it
requires platform-specific ifdefs when loading asset files, and this
defeats the purpose of base::PathServer.
This change adds cross-platform DIR_ASSETS that can be used on all
platforms. The values is platform specific:
  Win/Linux/ChromeOS: DIR_ASSETS = DIR_MODULE
  Mac: DIR_ASSETS = <bundle_path>/Resources
                    or DIR_MODULE when not bundled.
  Android: DIR_ASSETS = Undefined since resources are loaded from APK.
                        Overriden in test.
  Fuchsia: DIR_ASSETS = DIR_FUCHSIA_RESOURCE (i.e. /pkg)
                        or DIR_MODULE when not packaged.

Also removed DIR_FUCHSIA_RESOURCE and marked DIR_ANDROID_APP_DATA as
deprecated.

Bug: 805727, 617734
Change-Id: Id54305669f786c41c2dde0851daea1504547a866
Reviewed-on: https://chromium-review.googlesource.com/885002
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Kevin Marshall <kmarshall@chromium.org>
Commit-Queue: Sergey Ulanov <sergeyu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535118}
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/base/base_paths.cc
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/base/base_paths.h
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/base/base_paths_android.cc
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/base/base_paths_fuchsia.cc
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/base/base_paths_mac.mm
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/base/i18n/icu_util.cc
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/base/path_service_unittest.cc
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/base/test/test_support_android.cc
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/content/shell/app/shell_main_delegate.cc
[modify] https://crrev.com/d5ae68ebcd7cc869074e033de066d7f769477f16/gin/v8_initializer.cc

Sign in to add a comment