Added ability to insert pictures to Android Viewer.
You can take photo or select photo from device or
the cloud (Google photos, Dropbox). You can also
compress the picture before inserting it with multiple
compress grades. So far, inserting doesn't work for
Writer due LO native library issues (I think).
Change-Id: If6841ba04fe18585703c8b85909cf39747dbbc2f
Reviewed-on: https://gerrit.libreoffice.org/41150
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
packing gdbserver into apk conflicts with extractNativeLibs="false", as
the gradle pugin compresses it (which could be disabled using
aaptOptions), but furthermore it doesn't page-align it, breaking
installation.
So instead let the user manually push the gdbserver tool to device and
remove the hardcoded values that were only there to please the ndk-gdb
scripts.
Using lldb from within Android Studio is more comfortable anyway :-)
Change-Id: I31c3af4847a479c56b3fcd6b5bed114e004bf0d2
Reviewed-on: https://gerrit.libreoffice.org/41950
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Thanks to Petr Vorel for catching this.
Fixes portion of 66518ead51 that added
back the android:installLocation placeholder
Change-Id: Ibd3333dfafb65fabcb5df3f7a6626a00f5d71bc9
no need to extract the (huge) nativve lib to the device's filesystem on
newer android versions (Marshmallow and later) - can access the .so from
within the apk if it is uncompressed.
While the standalone apk will be larger, the delta-update mechanism of
playstore can be more efficient, so you get:
* faster installation (since the file doesn't need to be extracted)
* less disk usage on device (for same reason)
* smaller delta-updates for playstore
drawbacks
* larger standalone apk
* on older android version more storage needed (the increased size of
the standalone apk), as those will still extract the native-lib
Unfortunately uncompressed it exceeds the current maximum size for
single apk files in playstore (100MB), so cannot use for release-builds
also revive installLocation attribute to allow installation on external
storage and move from manifestPlaceholders from defaultConfig to release
buildType (as otherwise gradle complains about having "Multiple entries
with same key")
Change-Id: Id07ac9c144886bb89abaf7b5b4bc7bd548f27247
Fix the wrong parameter in AndroidManifest.
When changing android:windowSoftInputMode,
one should not specify multiple "adjust..." or "state...".
Change-Id: I0dcacd846d4fe5c2976fe1708b29086b98f2607b
Reviewed-on: https://gerrit.libreoffice.org/40686
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This commit adds the BottomSheetBehavior to the
formatting toolbar appearing from bottom.
CoordinatorLayout replaces the RelativeLayout in activity_main
and bottom toolbar is made the child of it.
Also, Add 'adjustPan' option to LibreOfficeMainActivity's
windowSoftInputMode flag so as to prevent soft keyboard
from pushing the views up
Change-Id: Ic9999c1177ac238bc7c482a69daec4e629fe6d93
Reviewed-on: https://gerrit.libreoffice.org/35768
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Uncomment in Manifest file the line related to input method:
android:windowSoftInputMode="adjustResize"
This allows for panning and zooming to the top part of the
document.
Change-Id: Ic75489071add6b52948d381f4f8b7205148b78ef
Reviewed-on: https://gerrit.libreoffice.org/35721
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
This commit improves the user experience of different
Document Providers in the app.
In case ext sd card is not present, the option is disabled
in Navigation Menu.
If the device does not support USB OTG,
the option is disabled.
LibreOfficeUIActivity registers a broadcast receiver
in onCreate which detects if a USB device is connected
and directs the user to Settings page to configure it.
In case of errors in configuration in any case,
user is directed to Settings activity after appropriate toast.
Change-Id: I680f78a679e2071ce8330c8168d7aa4e95041723
Reviewed-on: https://gerrit.libreoffice.org/34650
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
Replaced empty spinner with the document title in the Main (viewer)
activity. Had to edit the themes to not disable title, and edit the
manifest to make the desired activities use that theme. If the theme
is set in the "application" tag, it will apply the theme globablly.
Also cleaned up and tightened the ToolbarController.
Change-Id: I5099860787b5f84d01c98c5e53ade519c2f89cc4
Reviewed-on: https://gerrit.libreoffice.org/33306
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
Huge refactoring of the methods to use the passed instance of the
Context object instead of using the static one. I couldn't completely
remove the static object, because it requires restructuring of the
workflow so that it originates from the activity, and not from some
other random place. The way it was refactored is:
1. Find a place where the static object
(LibreOfficeMainActivity.mAppContext) is used.
2. Add a LibreOfficeMainActivity object to the method signature.
3. Repeat the process with a method that calls it, and repeat until
the LibreOfficeMainActivity object isn't available, so that it can be
passed through all the methods, to the place where the static object
was used.
4. Replace that static object with the parameter of the function.
The commit looks pretty huge, but it's basically just the simple
refactoring explained above. The memory leak isn't completely gone,
but this a progress towards it. Also moved the "global" objects of
Handler and LOKitThread from an Activity to an Application, which
is the correct place for "global" variables. Can someone explain why
Handler and LOKitThread are used? They seem to mostly do nothing, but
steeply increasing the complexity of the application.
Change-Id: Ib2be77fa3adea94d6b7849d0e2afa90bf318d68b
Reviewed-on: https://gerrit.libreoffice.org/33073
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
as non-native mipmap resolutions don't get stripped from the apk (as
drawables would), but launchers and similar might still want to show the
higher-res version instead. Google Play store now enforces this.
Also rename to the common name for it ("ic_launcher" instead of "main")
Change-Id: I97318287f05556f5db0afaa0b23c0d8c9628465e
Reviewed-on: https://gerrit.libreoffice.org/31204
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Background:
External SD cards are only partially supported by the Android system,
with a great deal of fragmentation on implementation across manufacturers
and android versions. There is no official support for OTG devices.
This commit adds:
1) External SD card support
2) OTG device support
Caveats:
1) Not tested on Android 6. Emulator crashes when opening
files on Android 6, using an unmodified build of the master branch.
2) OTG support currently works only if there is write access
to the OTG directory. The user must be aware of exact OTG directory
path or be able to navigate to it as well.
3) External SD card provider currently lacks file filtering.
Approach:
-----
Added new document providers.
External SD cards:
There are 2 different document providers external sd cards,
one for Android 4.4 and above, and the other for older versions.
1) New
Android 4.4 and above require usage of the DocumentFile wrapper class
to access files in external storage. Actual file paths are no longer
obtainable. As such, the underlying file will be cloned in a cache,
allowing us to get an actual file path and use LOK.
Some differences exist between 4.4 & 5+. The document provider handles
each case separately.
2) Legacy
Android 4.3 and below do not support the DocumentFile wrapper.
File object can be used in these versions, allowing actual file paths
to be obtained. The document provider guesses the root directory of
the SD card. If the guessing fails, the user is to navigate to
this directory himself.
OTG:
The OTG document provider resembles the legacy external SD card
document provider, requiring the user to locate the directory himself.
The document provider does not guess the root directory of the OTG
device as the location varies with manufacturer implementation.
-----
Supplementary Notes:
Attempting to use the internal app cache as the file cache like in
the ownCloud document provider did not work. Using the external app
cache works fine though. It could be because initializing LOK wipes
the internal app cache.
Would be good to test the ownCloud document provider to confirm if it
works.
Change-Id: Ie727cca265107bc49ca7e7b57130470f7fc52e06
Reviewed-on: https://gerrit.libreoffice.org/20738
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
move preparation tasks (creating assets/processing files) from the
makefile into the gradle script
This allows much easier integration into android-studio (just open
android/source with android studio after running make to compile the
native library)
Change-Id: I9a9d6832797c24a7e195a1c7954cd6d20f5a8496
Ximeng Zu