Depends on assets in http://crrev.com/15136005, which had to be separated because of the trybots.
With the way things are currently set up, Chrome on Android can't access properly
sized image resources:
* The APK only packages the mostly unused 100% resources (none of
the larger 200% assets)
* The bitmaps don't scale properly when they're converted to Java bitmaps because
the Java code knows nothing about the resource's expected dimensions on different
devices
* The Chromium resource loading system doesn't allow us to take advantage of
Android's resource loading schemes (drawable directories for different screen
sizes, RTL support, etc.).
Instead of #ifdefing out practically everything in the theme_resources.grd file,
this CL introduces a map between the chromium resource IDs and Android drawables,
allowing us to load up the correctly sized Android assets.
The template system is bootstrapped with the InfoBar and WebsiteSettingsUI icon
assets.
TBR=jochen
BUG=237034,238668
Review URL: https://chromiumcodereview.appspot.com/14772036
git-svn-id: http://src.chromium.org/svn/trunk/src/build@201328 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Eliminates NetworkListDetailedView and dependencies.
This mostly removes dead code, but also fixes the following
issues related to the old code:
* TrayNetwork::OnWillToggleWifi() ->
TrayNetwork::RequestToggleWifi() to toggle wifi directly
from Ash.
* Implement TrayNetwork::NetworkManagerChanged() so that
detailed views are notified when technology state changes.
* Eliminates unnecessary ash::SystemTrayDelegate
dependencies on network_menu_ when using new connection
handler code.
BUG=240859
For about_network.cc:
TBR=jamescook@chromium.org, jennyz@chromium.org
Review URL: https://codereview.chromium.org/15350002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@201322 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
grit now supports passing "-t android" to set the target platform to
android, which sets is_android and is_posix, and does *not* set
is_linux (matching the OS_* macros). Use this instead of defining an
"android" macro.
This requires one actual condition change in app_locale_settings as
the Android port was previously depending on is_linux being true for
its definitions of IDS_WEB_FONT_*. The other grd changes are all
trivial substitutions.
BUG=239434
TBR=jamesr@chromium.org, joi@chromium.org, newt@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/14834011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@201310 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Matches the flags to the OS X clang settings for C++11 to minimize
confusion, but it would be straightforward to enable the string literal
warning on iOS at this point.
Removes a warning suppression that's duplicated by an Xcode setting just
above (again, matching OS X)
BUG=226494
Review URL: https://chromiumcodereview.appspot.com/13936005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@201284 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Generates proper .def files that include "DATA" so that non-functions are
correctly exported.
However, for split_link because the "other" side won't import them properly
(__declspec(dllimport) is required) split_link notes them, and errors out.
This also adds support for linking individual objs out of libs so that some
_constants.cc and _switches.cc files can easily be linked into both DLLs.
R=cpu@chromium.org
BUG=237249
Review URL: https://codereview.chromium.org/15310002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@201119 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Gyp supports only very limited ways of changing behavior based upon
CONFIGURATION_NAME. Particularly, it does not support the way that was
supposed to enable/disable use of proguard.
Instead of trying to switch behavior in gyp, instead pass
CONFIGURATION_NAME, proguard_enabled, and
proguard_enabled_dex_input_path to dex.py and switch the behavior
there.
This also extracts the dex actions into build/android/dex_action.gypi
and uses that for the actions in both build/java.gypi and
build/java_apk.gypi.
BUG=240837
Review URL: https://chromiumcodereview.appspot.com/15231006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200958 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The comment in android_webview.gyp about static library dependencies not
being handled correctly is incorrect, and the workaround not necessary:
the problem was just that I wasn't using link_settings correctly. Remove
the workaround and instead add proper dependencies in the places that
actually use cpufeatures and cutils (ashmem). This doesn't change the
generated makefiles but makes more logical sense.
BUG=
R=digit@chromium.org
Review URL: https://codereview.chromium.org/14753011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200806 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This reverts the changes from commit 6394facfcd6150a69be418212f1caff2f6639540
and instead improves the adb_gdb script to properly auto-detect the right
location of the toolchain binaries.
This means that on a Linux 64-bit systems, it will first try to find the
64-bit binaries, and if not available, will fallback to 32-bit ones.
Tested with the default toolchain from third_party/android_tools/ndk/
(64-bit) and with --ndk-dir=/path/to/android-ndk-r8d (32-bit).
Also remove "gdb_apk" and "gdb_content_shell" which were obsoleted by
"adb_gdb" and "adb_gdb_content_shell", respectively.
BUG=none
R=yfriedman@chromium.org,navabi@chromium.org,wangxianzhu@chromium.org
Review URL: https://chromiumcodereview.appspot.com/14910010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200547 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This works around the bug we've had where on some Windows machines, one of the invocations of check_internal.py mysteriously causes a file to open up in Visual Studio. We have no idea why, but this should avoid the problem. See details in bug.
BUG=241208
Review URL: https://chromiumcodereview.appspot.com/12330155
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200514 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is achieved by having BaseTestRunner instantiate a single Forwarder
instance and inject it into SpawningServer.
This makes the test server spawner instance use an already configured Forwarder
instance for every single unit test rather than instantiating Forwarder every
time (which also meant unnecessarily running 'adb forward' for every single
unit test).
Note that this CL also makes Forwarder thread-safe. This is due to the fact
that the test server spawner does its work on a worker thread and not to the
fact that a single Forwarder instance can be shared accross multiple shards as
one could think.
BUG=229685,239014
R=bulach@chromium.org, craigdh@chromium.org, frankf@chromium.org
Review URL: https://codereview.chromium.org/15151003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200500 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
With the component build we need to always trigger stripping because we
can't specify the inputs correctly at gyp time. This is not required
for the non-component build.
Also, slightly refactor strip_native_libraries.gypi and its users to
make it more clear what variables are being used by the .gypi.
Review URL: https://chromiumcodereview.appspot.com/14844009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200422 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The compositor bindings for WebKit should only be used in a render process or in
webkit_support for DumpRenderTree or webkit_unit_tests. It's never used in a
browser process. This moves the bindings code under webkit/renderer/ so we can
enforce this via DEPS rules.
The path is unfortunately a bit awkward. Once we drop DumpRenderTreeSupport and
figure out a way to deal with webkit_unit_tests, we can move the bindings into
content/renderer/gpu/ since they'll only be used by the content embedding.
BUG=239107
TBR=piman@chromium.org
Review URL: https://codereview.chromium.org/14651027
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200350 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This patch implements the following changes to make it possible to run
the WebGL conformance test suite on Android:
1. Copy WebGL test data files to the device.
2. When running the conformance test, turn on WebGL with the
--enable-webgl command line flag.
3. Avoid validating the PCI vendor and device ids for the GPU because
Android has no such concept.
With these changes, you can run the WebGL conformance test by first
building content_browsertests_apk, removing the WebGL exclusion from
build/android/pylib/gtest/filter/content_browsertests_disabled and then executing:
$ build/android/run_browser_tests.py -f WebGLConformanceTest.*
BUG=138226
Review URL: https://chromiumcodereview.appspot.com/14944010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200298 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
There used not to be any way to unmap a previously forwarded port. Since
the host and device forwarder processes are kept alive during a whole test
suite, both the host and device ended up with an unnecessarily high amount of
unused open sockets. That is source of flakiness (e.g. too many opened file
descriptors).
This adds an UnmapDevicePort() method to the Python Forwarder wrapper class and
modifies the native forwarder2 to accept a negative port on the command line.
When a negative port is provided, the host forwarder tries to unmap that port
(that was mapped previously).
BUG=229685,239014
R=bulach@chromium.org, digit@chromium.org
Review URL: https://codereview.chromium.org/15008004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200257 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Added a spin-wait to cause the test to wait for the browser to create the BackingStore via its normal mechanism.
...and then I went ahead and refactored and cleaned up all the code. I did not add any significant additional testing. We will want to do this in a follow-up change. However, I did get rid of the #ifdef OS_XXX pragmas, so the tests will attempt to run on all platforms, not just Mac and Win, and use the CanXXX() methods to determine which features are supported for testing.
BUG=224351
Review URL: https://chromiumcodereview.appspot.com/14495016
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200226 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
First pass at split linker. Splits inputs based on json spec, uses .def files
to export symbols in the other half, relinks to generate an import lib, and
finally links again for the real link, using the generated def file and import
lib. And then, repeats those steps until success (not all unresolved externals
are reported by the linker on the first pass). It's necessary to use the
linker to report externals rather than cracking lib/objs because when doing
LTCG, the object files are in an undocumented compiler-internal format and the
exports can't be gathered (and probably aren't fully determined yet).
Currently this approach only handles chrome.dll, not other large targets that
are monolithic exes (rather than mostly in a DLL with an EXE loader).
Integrated with build system by a linker shim. Original link.exe is saved, and
replaced by split_link binary. If "/splitlink" is found on the command line,
then run our script that does the iterations/exporting magic. Otherwise,
fallback to the original linker.
When GYP_DEFINES includes chrome_split_dll=1, the split linker is invoked.
chrome.exe has not yet been modified to know how to load split binaries, so
the build flag will not yet be directly useful for those not working on this
problem.
Release, non-LTCG, non-split:
05/09/2013 04:57 PM 57,447,936 chrome.dll
Release, non-LTCG, split:
05/10/2013 12:47 PM 39,567,872 chrome0.dll
05/10/2013 12:48 PM 19,274,240 chrome1.dll
Release, partial-LTCG (same as current settings), split:
05/10/2013 03:56 PM 25,934,336 chrome0.dll
05/10/2013 04:13 PM 16,347,648 chrome1.dll
It should be possible to get higher optimization levels for chrome1.dll (or
perhaps both parts), but that can happen in subsequent changes after more
testing.
TBR=cpu@chromium.org, maruel@chromium.org
BUG=237249
Review URL: https://codereview.chromium.org/15067010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200049 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Next step on re-factoring Notifications. This will bring the MessageCenter classes, most important message_center::Notification, into build on all systems, including those where the MessageCenter is not yet appearign in UI. This will allow to start using this Notification class in client code and remove the old Notification class defined in chrome/browser/notificaitons/notification.h
That will allow the clients that already use Rich Notifications to use richer data type support, for example supply an image bits for a Notification (as in Snapshot notifications).
This also removes a lot of compile-time @ifdefs and replaces them with checking a runtime flag which we already have anyways.
On Android and iOS, the MessageCenter is not compiled in, for the size concerns and uncertain story for notifications in general - the existing ENABLE_NOTIFICATIONS define is used for that.
BUG=174164
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=199625
Review URL: https://chromiumcodereview.appspot.com/15025002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@199920 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When running tests, we should only be reinstalling the test apk if it
is different than the one currently installed. So, before reinstalling,
query the package manager for the path to the installed apk, and then
only reinstall if the md5sum of the installed apk differs from the one
we are about to install.
NOTRY=true
Review URL: https://chromiumcodereview.appspot.com/14601004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@199835 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Caused a static initializer on Linux:
# message_center_constants.cc __i686.get_pc_thunk.cx
(Not on Mac though. The SkGetColor() macro has a comment about it not adding
a static initializer on release builds, so maybe it's the float-int-multiplication?
I don't have a linux box around to check, sorry.)
> Remove ENABLE_MESSAGE_CENTER
>
> Next step on re-factoring Notifications. This will bring the MessageCenter classes, most important message_center::Notification, into build on all systems, including those where the MessageCenter is not yet appearign in UI. This will allow to start using this Notification class in client code and remove the old Notification class defined in chrome/browser/notificaitons/notification.h
>
> That will allow the clients that already use Rich Notifications to use richer data type support, for example supply an image bits for a Notification (as in Snapshot notifications).
>
> This also removes a lot of compile-time @ifdefs and replaces them with checking a runtime flag which we already have anyways.
>
> On Android and iOS, the MessageCenter is not compiled in, for the size concerns and uncertain story for notifications in general - the existing ENABLE_NOTIFICATIONS define is used for that.
>
> BUG=174164
>
> Review URL: https://chromiumcodereview.appspot.com/15025002TBR=dimich@chromium.org
Review URL: https://codereview.chromium.org/14631021
git-svn-id: http://src.chromium.org/svn/trunk/src/build@199639 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Next step on re-factoring Notifications. This will bring the MessageCenter classes, most important message_center::Notification, into build on all systems, including those where the MessageCenter is not yet appearign in UI. This will allow to start using this Notification class in client code and remove the old Notification class defined in chrome/browser/notificaitons/notification.h
That will allow the clients that already use Rich Notifications to use richer data type support, for example supply an image bits for a Notification (as in Snapshot notifications).
This also removes a lot of compile-time @ifdefs and replaces them with checking a runtime flag which we already have anyways.
On Android and iOS, the MessageCenter is not compiled in, for the size concerns and uncertain story for notifications in general - the existing ENABLE_NOTIFICATIONS define is used for that.
BUG=174164
Review URL: https://chromiumcodereview.appspot.com/15025002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@199625 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
dfalcantara@chromium.org
stevenjb@chromium.org
torne@chromium.org
stuartmorgan@chromium.org
scottmg@chromium.org
halton.huo@intel.com
yusufo@chromium.org
ilevy@chromium.org
thakis@chromium.org
phajdan.jr@chromium.org
cjhopman@chromium.org
mkosiba@chromium.org
henrika@chromium.org
digit@chromium.org
joi@chromium.org
pliard@chromium.org
jamesr@chromium.org
zmo@chromium.org
skyostil@chromium.org
miu@chromium.org
palmer@chromium.org
rsleevi@chromium.org
thestig@chromium.org
chrisgao@chromium.org
navabi@chromium.org
eugenis@chromium.org
kkania@chromium.org
dimich@chromium.org
justincohen@google.com
jochen@chromium.org