Fallback for loading library from a zipfile.

Fallback for loading library from a zipfile. This approach copies the
library out of the zip file into a separate file and loads it from there.
This fallback approach should work for corrupted zip files, but not for
SELinux issues on which occur on some Samsung devices. Change needs
further work to detect corrupted zip files.

BUG=

Closed as Petr, committed this in:
https://codereview.chromium.org/684163002/

[Anton, 2014-10-24 16:47:45]

anton@chromium.org changed reviewers:
+ petrcermak@chromium.org

[Anton, 2014-10-24 16:47:45]

Not really for review at this stage.

[picksi1, 2014-10-28 12:25:26]

picksi@chromium.org changed reviewers:
+ picksi@chromium.org

[picksi1, 2014-10-28 12:25:27]

I don't know if this code is ready for reviews, but I have a couple of nits!

https://codereview.chromium.org/673093005/diff/1/base/android/java/src/org/ch...
File base/android/java/src/org/chromium/base/library_loader/Linker.java (right):

https://codereview.chromium.org/673093005/diff/1/base/android/java/src/org/ch...
base/android/java/src/org/chromium/base/library_loader/Linker.java:997: }
Should the above block of code be re-jigged slightly and moved into its own
function called (e.g.) removeOutOfDateFallBackFile(). The code could then be
re-arranged to look like:

removeOutOfDateFallBackFile();
useExistingFallbackFile = fallbackLib.exists();

So 'fallbackLib.exists()' becomes the golden source for using the fallback or
not.

https://codereview.chromium.org/673093005/diff/1/base/android/java/src/org/ch...
base/android/java/src/org/chromium/base/library_loader/Linker.java:1040: byte[]
buffer = new byte[4096];
Will this leak? Or does 'byte' contain a destructor that fixes it up?

https://codereview.chromium.org/673093005/diff/1/third_party/android_crazy_li...
File third_party/android_crazy_linker/src/src/crazy_linker_api.cpp (right):

https://codereview.chromium.org/673093005/diff/1/third_party/android_crazy_li...
third_party/android_crazy_linker/src/src/crazy_linker_api.cpp:234:
buffer[pathname.size()] = '\0';
Would strncpy(buffer, pathname.c_str(), pathname.size()) be clearer?

https://codereview.chromium.org/673093005/diff/1/third_party/android_crazy_li...
File third_party/android_crazy_linker/src/src/crazy_linker_library_list.cpp
(right):

https://codereview.chromium.org/673093005/diff/1/third_party/android_crazy_li...
third_party/android_crazy_linker/src/src/crazy_linker_library_list.cpp:416: if
(fullname.size() + 1 > kMaxFilenameInZip) {
Should this be >= without the +1 as happens elsewhere?

[Anton, 2014-10-28 12:42:15]

This change isn't ready for submission (and maybe eclipsed by Petr's changed),
but comments are fine at this point.

https://codereview.chromium.org/673093005/diff/1/base/android/java/src/org/ch...
File base/android/java/src/org/chromium/base/library_loader/Linker.java (right):

https://codereview.chromium.org/673093005/diff/1/base/android/java/src/org/ch...
base/android/java/src/org/chromium/base/library_loader/Linker.java:997: }
On 2014/10/28 12:25:26, picksi1 wrote:
> Should the above block of code be re-jigged slightly and moved into its own
> function called (e.g.) removeOutOfDateFallBackFile(). The code could then be
> re-arranged to look like:
> 
> removeOutOfDateFallBackFile();
> useExistingFallbackFile = fallbackLib.exists();
> 
> So 'fallbackLib.exists()' becomes the golden source for using the fallback or
> not.

Agreed to the decomposition. Though fallbackLib.exists() is not a good source of
truth. I particular, deletion is best effort and can fail. I think that the
renderer may not be able to delete a file made by the browser (for example).

https://codereview.chromium.org/673093005/diff/1/base/android/java/src/org/ch...
base/android/java/src/org/chromium/base/library_loader/Linker.java:1040: byte[]
buffer = new byte[4096];
On 2014/10/28 12:25:26, picksi1 wrote:
> Will this leak? Or does 'byte' contain a destructor that fixes it up?

Nope. This is Java it is garbage collected.

https://codereview.chromium.org/673093005/diff/1/third_party/android_crazy_li...
File third_party/android_crazy_linker/src/src/crazy_linker_api.cpp (right):

https://codereview.chromium.org/673093005/diff/1/third_party/android_crazy_li...
third_party/android_crazy_linker/src/src/crazy_linker_api.cpp:234:
buffer[pathname.size()] = '\0';
On 2014/10/28 12:25:26, picksi1 wrote:
> Would strncpy(buffer, pathname.c_str(), pathname.size()) be clearer?

Agreed, though strncpy does not guarantee the null '\0', so you still want for
buffer[pathname.size()] = '\0' for safety.

https://codereview.chromium.org/673093005/diff/1/third_party/android_crazy_li...
File third_party/android_crazy_linker/src/src/crazy_linker_library_list.cpp
(right):

https://codereview.chromium.org/673093005/diff/1/third_party/android_crazy_li...
third_party/android_crazy_linker/src/src/crazy_linker_library_list.cpp:416: if
(fullname.size() + 1 > kMaxFilenameInZip) {
On 2014/10/28 12:25:27, picksi1 wrote:
> Should this be >= without the +1 as happens elsewhere?

Agreed