Enable support for MIME type
"application/vnd.oasis.opendocument.spreadsheet-flat-xml" in
AndroidManifest, the comment saying it crashes the app
is obsolete.
However, at least on my Android 10 AVD, that MIME type
does not seem to be associated with '*.fods' files, so
they were not offered to be opened. MIME type
"application/octet-stream" was used instead, for which
no support is declared.
For testing, I just disabled the MIME type filter locally and
was then able to open an FODS file just fine:
--- a/android/source/src/java/org/libreoffice/ui/LibreOfficeUIActivity.java
+++ b/android/source/src/java/org/libreoffice/ui/LibreOfficeUIActivity.java
@@ -266,7 +266,7 @@ public class LibreOfficeUIActivity extends AppCompatActivity implements Settings
}
intent.setType("*/*");
- intent.putExtra(Intent.EXTRA_MIME_TYPES, SUPPORTED_MIME_TYPES);;
+ //intent.putExtra(Intent.EXTRA_MIME_TYPES, SUPPORTED_MIME_TYPES);;
Change-Id: Ibf3f559a313f0b89bc4c25498e3efa0fcbded506
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132263
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Android Viewer had its own file abstraction layer.
From the (now deleted) IFile.java:
> An abstraction of the File class, intended to be implemented by different
> Document Providers.
>
> It represents a file or a directory in the context of a certain Document
> Provider. It wraps the file-related operations and provides access to the
> final document as a local File, downloading it if necessary.
However, Android already provides such an abstraction by
what is called "documents provider" there as well, s. [1].
Android Viewer has previously been adapted to
support and make use of that.
Therefore, drop the custom implementation to avoid
duplication and having to reimplement functionality
already provided otherwise.
Also, drop the custom UI elements to display and
select files implemented on top of the custom
file abstraction. Support for using the system file
picker (via the corresponding Intents) has been added
earlier and is now the only available option to open
files from within the app.
[1] https://developer.android.com/training/data-storage/shared/documents-files
Change-Id: Ide529e836a32fd7e880e5a72d971af9f9c7e74bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113667
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The permission was requested since ownCloud support was added
in commit 69773f54bb
("Android: initial implementation of ownCloud provider.",
2015-01-21).
Since the custom ownCloud support has been dropped in commit
6012599e17
("tdf#129833 android: Drop non-working ownCloud/nextCloud support"),
there should no longer be any need to require Internet access,
so drop the permission again.
Access to ownCloud and other Internet services providing file
access now goes via DocumentProviders, and the corresponding
apps providing those should take care of
being allowed to access the internet by themselves.
I tested that opening and editing a file located
on a NextCloud share still works OK when the NextCloud
app is installed and set up.
Change-Id: Id8425e7afcd5ecc26d14ba9f42018f536d0a6a6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112879
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Commit 66518ead51
("use extractNativeLibs="false" for less disk usage and
faster installation", 2017-08-31) had set
'extractNativeLibs="false"' in Android's manifest
for the debug build case, which prevented the shared native
libraries from being extracted on the device.
However, while e.g. liblo-native-code.so can be handled just
fine when it is in the APK in uncompressed form, the
NSS library tries to load modules at runtime by using an
explicit path to the module
(like '/data/user/0/org.libreoffice/lib/libnssckbi.so';
due to 'LO_LIB_DIR=file://$APP_DATA_DIR/lib/' set in
fundamentalrc (as defined in build.gradle)), but the
library was no longer there, so NSS
initalization failed (s. 'nsscrypto_initialize').
As a result, Android Viewer was unable to open
encrypted/password-protected files.
Therefore, extract the libs again for the debug case
as well to make that work again. (Release mode
still had 'extractNativeLibs="true"' anyway.)
Side note 1: According to [1], it should in general
also be possible to use 'dlopen()' for dynamic libraries
inside zip files (like the APK):
> Note that in API level 23 and above dlopen(3) will
> open a library from any zip file, not just your APK.
> Just give dlopen(3) a path of the form
> "my_zip_file.zip!/libs/libstuff.so". As with APKs,
> the library must be page-aligned and stored uncompressed
> for this to work.
In any case, if that approach were to be taken, that
would need some closer look to make it work, e.g. how to
retrieve the actual location of the APK file, how to treat
the different architecturs, whether that works for all
supported Android versions,...
Side note 2: To debug into the NSS library,
temporarily avoiding stripping the debug information
as follows helped:
--- a/android/Bootstrap/Makefile.shared
+++ b/android/Bootstrap/Makefile.shared
@@ -68,7 +68,7 @@ $(SODEST)/liblo-native-code.so : $(OBJLOCAL)/liblo-native-code.so
$(SODEST)/nss-libraries :
mkdir -p $(SODEST)
- $(foreach lib,$(NSSLIBS),$(STRIP) -o $(SODEST)/lib$(lib).so $(INSTDIR)/$(LIBO_LIB_FOLDER)/lib$(lib).so;)
+ $(foreach lib,$(NSSLIBS),cp $(INSTDIR)/$(LIBO_LIB_FOLDER)/lib$(lib).so $(SODEST)/lib$(lib).so;)
$(SODEST)/libc++_shared.so : $(ANDROID_NDK_HOME)/sources/cxx-stl/llvm-libc++/libs/$(ANDROID_APP_ABI)/libc++_shared.so
cp $< $@
[1] https://github.com/aosp-mirror/platform_bionic/blob/master/android-changes-for-ndk-developers.md#opening-shared-libraries-directly-from-an-apk
Change-Id: I7631e4a1e5e3d7b3b589ba09d62b52dc5c55836c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91229
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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
Michael Weghorn