In the past, LibreOffice Viewer for Android was directly
accessing storage in order to open/save files and when
exporting to PDF.
However, that was switched to using Android's Storage
Access Framework [1], available since Android 4.4
(API level 19), i.e. it is available in all Android
versions supported by the app.
In the past, in order to directly access storage, permission
android.permission.WRITE_EXTERNAL_STORAGE was needed.
That permission no longer has any effect in
Android 11 (API level 30) or higher, quoting from [2]:
> More recent versions of Android rely more on a file's purpose than its
> location for determining an app's ability to access, and write to, a
> given file. In particular, if your app targets Android 11 (API level 30)
> or higher, the WRITE_EXTERNAL_STORAGE permission doesn't have any
> effect on your app's access to storage. This purpose-based storage
> model improves user privacy because apps are given access only to
> the areas of the device's file system that they actually use.
>
> Android 11 introduces the MANAGE_EXTERNAL_STORAGE permission, which
> provides write access to files outside the app-specific directory and
> MediaStore. To learn more about this permission, and why most apps don't
> need to declare it to fulfill their use cases, see the guide on how to
> manage all files [3] on a storage device.
Since PDF export was also switched to use the
Android Storage Framework mechanism in
commit 9ebcb80e2e
Author: Michael Weghorn
Date: Thu Apr 15 11:22:46 2021 +0200
android: Ask where to save PDF file on export
, eventually drop the permission now.
As mentioned in
commit 7d9db806d6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Apr 9 11:24:16 2021 +0200
android: Request PERMISSION_WRITE_EXTERNAL_STORAGE again
which re-requested the permission before PDF export was
ported to use the Android Storage Framework, the case of
applications passing documents via a file:// URI would also
require storage permission in order to access the file.
However, apps that properly pass the file should pass a
content:// URL instead.
Quoting from the Android 7.0 Behavior changes
documentation [4]:
> Passing file:// URIs outside the package domain may leave the receiver
> with an unaccessible path. Therefore, attempts to pass a file:// URI
> trigger a FileUriExposedException. The recommended way to share the
> content of a private file is using the FileProvider.
(Using content:// URIs has been possible long before Android 7.0,
however.)
Therefore, drop support for file:// URIs as well, which
will prevent apps that would otherwise try to pass file://
URIs from trying to do that for Android Viewer.
If this results in any app no longer being able to
open documents in LibreOffice Viewer, that app most
likely needs to be adjusted to pass a content:// URI instead,
which will also make it work for newer Android versions.
(Total Commander is one case that apparently doesn't do
that yet, previously resulting in a crash when storage
permissions were not granted, see tdf#164082. That is
reproducible in an Android 7.0 AVD, while opening
the file fromm other apps, e.g. from Material Files [5],
works perfectly fine, using content:// URIs.)
Eventually dropping the permission makes clear that
the app does not need direct storage access, which is
also relevant for security reviews, and addresses this
lint issue from android/source/lint-baseline.xml:
<issue
id="ScopedStorage"
message="WRITE_EXTERNAL_STORAGE is deprecated (and is not granted) when targeting Android 13+. If you need to write to shared storage, use the `MediaStore.createWriteRequest` intent."
errorLine1=" <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>"
errorLine2=" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~">
<location
file="AndroidManifest.xml"
line="9"
column="36"/>
</issue>
That file will be updated/regenerated in a separate
commit.
[1] https://developer.android.com/training/data-storage/shared/documents-files
[2] https://developer.android.com/training/data-storage#permissions
[3] https://developer.android.com/training/data-storage/manage-all-files
[4] https://developer.android.com/about/versions/nougat/android-7.0-changes
[5] https://f-droid.org/en/packages/me.zhanghai.android.files/
Change-Id: Iafb7a32668718afc638b8273a05a9d0618f85550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194215
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This android.hardware.usb.host feature element was added in
commit 5ada20b358
Author: brainbreaker <gautamprajapati06@gmail.com>
Date: Sun Feb 26 02:27:43 2017 +0530
Improve the Document Provider UX
, when it was still used for the file/document access
logic implemented in the app that was also explicitly
handling USB device support.
That one was dropped in
commit a23bd42e9b
Author: Michael Weghorn
Date: Tue Apr 6 14:26:06 2021 +0200
android: Drop custom file abstraction + UI
, so also drop this from the Android manifest.
Change-Id: Icbd8fa86d1a9a4d8dfb8fccd90846a432a329b90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194214
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Don't use another theme for the SettingsActivity
than for the rest of the app.
I don't see any big visual change when opening
the activity at least in an API 36 (Android 16)
AVD anyway (with an additional
local revert of commit 9d1e76f7da
to prevent a deadlock when opening documents that is unrelated
to this change here)
and this will simplify maintenance and
adding support for targetSdkVersion 35 where edge-to-edge
is enabled by default [1].
[1] https://developer.android.com/about/versions/15/behavior-changes-15#window-insets
Change-Id: I1e5dccfefe930d34a8b315df04a6f07f050a5b54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187626
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
At least on recent devices (seen e.g. on an AVD
with API level 34 and a Fairphone 3 with LineageOS 20
(based on Android 13)), inserting a picture by
taking a photo using the camera didn't work,
"nothing was happening" when choosing the corresponding
option from the formatting toolbar with experimental
editing mode enabled.
This is due to the system filtering information about
other apps/packages with target API level >= 30 for
privacy reasons, see [1] for more details.
As described at [2], requesting the `CAMERA`
permission is not required:
> Users might take pictures in your app, using the pre-installed
> system camera app.
>
> In this situation, don't declare the CAMERA permission. Instead,
> invoke the ACTION_IMAGE_CAPTURE intent action.
In fact, specifying the permission is even counter-productive
and would cause this to not work, as also described at [2]:
> Note: If your app declares Manifest.permission.CAMERA
> permission and is not granted, then the action results in
> a SecurityException.
Rather than explicitly requesting the permission, just
drop it from the AndroidManifest, as it's not needed.
Also drop the additional code interacting with the package
manager, as that doesn't work with newer API
versions as described above.
With these changes in place, inserting a photo works fine
in tests in API 21 and API 34 AVDs and on the
above-mentioned Fairphone 3.
[1] https://developer.android.com/training/package-visibility
[2] https://developer.android.com/privacy-and-security/minimize-permission-requests#take-photo
Change-Id: Ia1ee4e4de577a269e2b79bf5460d08b1bf2bee56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167603
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Check for `FEATURE_CAMERA_ANY` ("The device has at least
one camera pointing in some direction, or can support an
external camera being connected to it.") [1] instead
of only the rear camera via `FEATURE_CAMERA`
("The device has a camera facing away from the screen.") [2]
when taking a photo is selected in the "Insert" menu, as
there's no need to restrict this to the rear camera.
This addresses this warning shown in Android Studio:
> You should look for any camera available on the device, not just the rear
Note however that trying to use that feature (with or
without this change in place) currently doesn't actually
work at least on a current device (e.g. an API 34 AVD),
"nothing happens" rather than the camera showing up to
be able to take a photo. This will be addressed
in an upcoming commit.
[1] https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_CAMERA_ANY
[2] https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_CAMERA
Change-Id: I52d2147df8fb3f1fdfb277376d7796380f9a8da0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167602
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As described in more detail in
commit 45fbfbfeae
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Mar 27 17:04:37 2020 +0100
tdf#131622 android: Extract native libs again
, extracting native libraries was necessary for the NSS
library to be able to load modules like `libnssckbi.so`
at runtime. Without this, opening password-protected
files would fail.
However, this has in the meanwhile been addressed
differently in the following commit (probably in the
context of the online-based/Collabora Online app), so
extracting libs is no longer needed:
commit 16a7f98f99
Author: Mert Tumer <mert.tumer@collabora.com>
Date: Wed Sep 30 17:14:59 2020 +0300
Fix libnssckbi not found error on Android
This error causes Android App to be unable to
open Password-protected documents.
Change-Id: Iacbacb1c780025752e2447db325b075c58947818
Signed-off-by: Mert Tumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103658
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Therefore, no longer extract the libraries, which also addresses
addresses this warning shown during the build:
> Task :processStrippedUIEditingDebugMainManifest
.../android/source/AndroidManifest.xml:16:9-41 Warning:
android:extractNativeLibs should not be specified in this source AndroidManifest.xml file. See https://d.android.com/guide/topics/manifest/application-element#extractNativeLibs for more information.
The AGP Upgrade Assistant can remove the attribute from the AndroidManifest.xml file and update the build file accordingly. See https://d.android.com/studio/build/agp-upgrade-assistant for more information.
Change-Id: I867beea0bce8398806375048e87a152e1348d016
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160079
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Support dark theme by inheriting from the
corresponding "AppCompat.DayNight" themes rather than
forcing the use of a light theme by using the
"AppCompat.Light" variants, s.a. [1].
With this in place, the app will automatically use a
dark theme for the Android UI controls when that's
enabled in the Android system settings.
Toolbars and menus mostly look as expected.
The bottom toolbar will be handled separately.
Icons will also have to be adapted in a follow-up
step to provide for better contrast, since they're
currently designed for light mode/white background.
[1] https://developer.android.com/develop/ui/views/theming/darktheme#themes-styles
Change-Id: Ia08edcc9d22b93caa67b146dcf90ee5fd02ee550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160068
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from the now deprecated way, as mentioned in
commit 7347d911fa295c31262a0f576c5b2f3f14ce017d
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Dec 23 18:29:44 2022 +0100
android: Update Android Gradle Plugin to 7.3.1
... and gradle to 7.4.
Relevant entry from the release notes [1] that will be
addressed in a follow-up commit:
> # Package attribute in manifest file is deprecated
>
> Starting with AGP 7.3.0-alpha04, if you use Gradle to build your
> project, AGP generates a warning if you use the package attribute in the
> manifest file. To set the namespace for your app, use the namespace
> property in the module-level build.gradle file. To learn more, see Set a
> namespace
> [https://developer.android.com/studio/build/configure-app-module#set-namespace].
>
> To get help moving to the new namespace DSL, use the AGP Upgrade
> Assistant (Tools > AGP Upgrade Assistant).
[1] https://developer.android.com/studio/releases/gradle-plugin#7-3-0
Change-Id: I8b196e53fb9b3fb7e9314719fdb7e0f2254abd10
Note that this is unrelated to the Android application ID [1]
that can be set with autogen param `--with-android-package-name`.
[1] https://developer.android.com/studio/build/configure-app-module#set-application-id
Change-Id: I146dab19228d83b1beb6408743c0232e1ba1d060
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144836
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Opening the sample file of MIME type
"application/vnd.openxmlformats-officedocument.presentationml.slideshow"
attached to tdf#111427 worked fine now when testing in an x86_64 AVD
with API level 31, so declare support for it.
Change-Id: I67ace0fb6ee82c0a43624dc32671ba2d453e473c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133648
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Android Studio was showing an info/warning in the "Problems"
pane that this label is redundant, so remove it.
(The app name is used by default if nothing else is specified
anyway.)
Change-Id: I799c681488b95e2fffe89b59e7de18febe654dcb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133174
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Google Play now requires that apps target API level 30 or higher, and
compileSdkVersion/targetSdkVersion 31 is also needed to update
the com.google.android.material dependency to >= 1.5.0 [1].
Explicitly set the `android:exported="true"` attribute for activities
which is required when targeting Android 12 or newer; quoting from
the list of behavior changes for apps targeting Android 12 [1]:
> Safer component exporting
>
> If your app targets Android 12 or higher and contains activities,
> services, or broadcast receivers that use intent filters, you must
> explicitly declare the android:exported attribute for these app
> components. Warning: If an activity, service, or broadcast receiver
> uses intent filters and doesn't have an explicitly-declared value for
> android:exported, your app can't be installed on a device that runs
> Android 12 or higher.
>
> If the app component includes the LAUNCHER category, set
> android:exported to true. In most other cases, set android:exported
> to false.
>
> The following code snippet shows an example of a service that
> contains an intent filter whose android:exported attribute is set to
> false:
>
> <service android:name="com.example.app.backgroundService"
> android:exported="false">
> <intent-filter>
> <action android:name="com.example.app.START_BACKGROUND" />
> </intent-filter>
> </service>
The app worked fine in a quick test on an x86_64 AVD with API level 31.
[1] https://github.com/material-components/material-components-android/releases/tag/1.5.0-alpha03
Change-Id: Ibb919e4edb995740e48ebc3338ffab6ca35c1373
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Replace the no longer maintained Android Support Library
with the Android Jetpack libraries.
Quoting [1]:
> Version 28.0.0 is the last release of the Support Library. There will be
> no more android.support library releases. All new feature development
> will be in the androidx namespace.
Most porting was done automatically by using Android Studio's
"Refactor" -> "Migrate to AndroidX..." function.
In `android/source/res/layout/toolbar_bottom.xml` and
`android/source/res/layout/toolbar_color_picker.xml`,
the uses of
`app:layout_behavior="android.support.design.widget.BottomSheetBehavior"`
had to be replaced manually as described at [2], because
the app would crash when using the old "android.support"
values.
Also drop the Android Support Library related bits from configure.ac
In a quick test, this worked fine and no obvious
difference was visible when running this in various AVDs.
When trying to test this in an x86 AVD still using
SDK 16 (Android 4.1), which is currently specified
as Android Viewer's `minSdkVersion`, only various
unrelated issues showed up, some of which will be
handled in follow-up commits.
After the migration, many weird errors showed up in
Android Studio, which disappeared after invalidating
the caches (via "File" -> "Invalidate Caches...").
[1] https://developer.android.com/jetpack/androidx
[2] https://stackoverflow.com/questions/45100963/runtimeexception-could-not-inflate-behavior-subclass
Change-Id: I2a57f0ebd56e7ecc09b7d65aae17fd15088a633b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133002
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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