Remove SkWindow::onPDFSaved, it does not work and it is not used anymore.
Also, it is very SampleApp -specific feature implemented in SkWindow class.
SkWindow class is probably intended to be more app-agnosting than
what this method implies.
Presumably the idea of the callback was to inform the user of
SampleApp that the PDF was saved to a certain location.
For Android SampleApp, show a hardcoded toast that the PDF was saved to
/sdcard.
BUG=skia:4733
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1547923002
Review URL: https://codereview.chromium.org/1547923002
This should prevent the Android bots running out of battery at the
expense of extra time spent waiting at the end of the build.
BUG=skia:4606
Review URL: https://codereview.chromium.org/1522013002
1) com.skia -> com.skia.sample_app
2) pass arguments to android_gdb_app to android_setup.sh so you can build gdbserver binaries for your actual device(rather than default arm64). This allows you to run it like this for example:
./platform_tools/android/bin/android_gdb_app -d nexus_6
BUG=skia:
DOCS_PREVIEW= https://skia.org/?cl=1509853006
Review URL: https://codereview.chromium.org/1509853006
The script runs through the directory of JSON files, capturing SKPs from
the apps specified by the JSON files.
BUG=skia:
Review URL: https://codereview.chromium.org/1483063006
Disable SkImageDecoder's code which relies on Android's customized
libpng and libjpeg. Build standard versions of libpng and libjpeg-turbo
everywhere. The SkImageDecoder code has been replaced with SkCodec, which
can decode subsets using standard library APIs
BUG=skia:
Review URL: https://codereview.chromium.org/1406153015
- This updates to r10e / API v21 everywhere.
- This has each host machine fetch the NDK,
run make-standalone-toolchain.sh, and copy gdbserver itself.
(It will do all this once per $ARCH, which is a little inefficient, but it
washes out in steady state.)
BUG=skia:
Review URL: https://codereview.chromium.org/1385463002
Compare Ganesh and HWUI canvas rendering of SKPs on android.
Put SKP files in .../canvasproof/src/main/assets/skps
Run on a Marshmallow device.
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/1258123004
This should still wait for the device to be attached and finished
booting, but will prevent no-output timeouts due to
`adb wait-for-device` never finishing.
The effect should be that, when an Android device is disconnected, the
"wait for device" step will run forever, or until the device
reconnects. This should prevent a disconnected device from spreading
purple all over the status page.
BUG=skia:
Review URL: https://codereview.chromium.org/1315753010
Compile SkJpegCodec and SkImageDecoder_libjpeg with
chromium's libjpeg-turbo. SkImageDecoder_libjpeg still uses
libjpeg on Android and the Android framework. SkJpegCodec is
still not compiled on the Android framework.
BUG=skia:
Review URL: https://codereview.chromium.org/1275773004
Currently the SampleApp and VisualBench builds for Android don't work
for rebuilds. The code is re-built, but the apks are not. This
results from the use of a directory as 'output' and the action to
build the apk not depending on the copied libraries.
Review URL: https://codereview.chromium.org/1270643005
It turns out that gyp (kind of) has support for cross
compiling with a different host and target. We simply
need to specify CC_host and CC_target instead of CC.
Making this change allows us to compile yasm on a Linux
host for Android.
We run into problems on Mac because
the linker on a Mac host requires different command line
arguments than the linker on the Android target. In
looking through the code for gyp itself and speaking to
Ben, it doesn't appear to me that gyp supports passing
different arguments to host and target linkers.
I would imagine that we would have similar problems on
Windows.
Below is a link to a CL that would fix this issue in gyp.
It looks like it has been dropped for a long time.
Thanks to Ben for this link!
https://chromiumcodereview.appspot.com/10795044/
Also I'm adding a link to the build instructions for Chrome
(thanks again Ben). It looks like they only support
building for Android from Linux.
https://code.google.com/p/chromium/wiki/AndroidBuildInstructions
My next steps are:
1) Getting in touch with Torne or someone else with gyp to
see if people are aware of this issue or interested in
fixing it.
2) Deciding if skia should care about this issue.
3) Deciding if skia should work around this issue.
It'd be really great to hear your thoughts on (2) and (3).
My first thought is that we shouldn't care because, as
long as we always compile the production copy of skia for
Android on Linux, we will get the fast code. Is this
a valid conclusion? Is there a way to write Android apps
on Mac that accidentally use the slower code?
If we do care, there are workarounds:
For Mac, we can check in a yasm binary - it's a little
smaller than the one I am deleting in this CL :-/
For Windows, we *might* be able to use the yasm.exe binary
already in externals (we get this from DEPS because this is
how chromium uses yasm on Windows).
Are there other platforms that we care about?
Let me know what you think!
BUG=skia:4028
DOCS_PREVIEW= https://skia.org/?cl=1239333002
Review URL: https://codereview.chromium.org/1239333002
