In debug mode Android package name is "org.example.libreoffice"
and "make run" said that there is no such intent to launch.
Change-Id: I6d8eac85dedf3e387a9dd4a228605f79ca0d5aee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103287
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...after 5fdf2009d21fa220dfee70ea755bd698c16257a7 "tdf#134522 remove
--with-build-version ./configure flag", 00fa759dc9f13eb4618a7762be9ca6eaf3fd37f7
"tdf#135133: Don't try to read BuildVersion", and
6ee46adb446f5350df2b1efc7fc3ffe2506dfaa0 "Remove BuildVersion from installation
set version ini files" already removed it from anywhere else
Change-Id: I42ccf35d6952ad0a826517ecadfe0ebb3bb704a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101003
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
commit 0dffc65236fbacf98047d6dbfc82b4efe7dd959b
Date: Fri Jun 5 08:59:26 2020 -0400
android: fix the build output directory
submitted on 2020-07-07 had changed the output directory
for native libraries, so the directory used by
Android Viewer was empty, and native libs no longer
contained in the package/APK.
Store the actual/new directory in a variable and
use that one in build.gradle to make things work
again.
Change-Id: I5a051342278ab14e71edf47dd93e8dacdb9f3cb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98970
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Without it, Android Viewer crashes in experimental editing
mode when e.g. opening the sample doc and clicking into the
text area.
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: org.libreoffice, PID: 6152
E AndroidRuntime: java.lang.NullPointerException: Attempt to read from field 'float android.graphics.RectF.left' on a null object reference
E AndroidRuntime: at org.mozilla.gecko.gfx.RectUtils.scale(RectUtils.java:45)
E AndroidRuntime: at org.libreoffice.overlay.DocumentOverlayView.convertToScreen(DocumentOverlayView.java:194)
E AndroidRuntime: at org.libreoffice.overlay.DocumentOverlayView.repositionWithViewport(DocumentOverlayView.java:184)
E AndroidRuntime: at org.libreoffice.overlay.DocumentOverlayView.changeGraphicSelection(DocumentOverlayView.java:157)
E AndroidRuntime: at org.libreoffice.overlay.DocumentOverlay$11.run(DocumentOverlay.java:199)
E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:883)
E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:100)
E AndroidRuntime: at android.os.Looper.loop(Looper.java:214)
E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7356)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
Change-Id: Ibff148a5d83413b4eed8a054b0143c9dae4e5537
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97632
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This moves the classes from juh.jar and ridl.jar to libreoffice.jar
The goal is to have one single jar (and Java module, will be added later)
which developers can include to work with LO.
juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar
on its classpath to keep backwards compatibility.
This is a continuation of ae855bf48163ff64d94cfc34aff8e37abdb5518d
and a preparation to have Java 9 module support.
Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Otherwise, Android Viewer crashes when clicking inside
a header or footer, failing to access the file:
E libo:sal/osl/unx/file: failed to open /assets//config/soffice.cfg/modules/swriter/ui/headerfootermenu.ui
W vcl.builder: 2:vcl/source/window/builder.cxx:481: DBG_UNHANDLED_EXCEPTION in VclBuilder::VclBuilder(vcl::Window *, const rtl::OUString &, const rtl::OUString &, const rtl::OString &, const css::uno::Reference<css::frame::XFrame> &, bool, const NotebookBarAddonsItem *)
W vcl.builder: when: Unable to read .ui file exception: com.sun.star.container.NoSuchElementException message: file:///assets//config/soffice.cfg/modules/swriter/ui/headerfootermenu.ui
I stderr : terminating with uncaught exception of type com::sun:⭐:container::NoSuchElementException
Change-Id: Iaf95e3dd2dbd9c471c8e1b3facabe21c93c47622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91865
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Since the 'refresh()' in 'LOKitThread::loadDocument' is
not executed synchronously but posted to the main handler,
this needs to be synchronized to prevent the document from
being deleted while it's being used.
The problem when pressing the "back" button while loading
the document was that LOKitThread::closeDocument would
cause the document to be deleted while it was still
being used, causing a crash on C++ side when using the
dangling pointer to the document in function
'doc_getDocumentType' (desktop/source/lib/init.cxx).
Change-Id: I37da4c4cf8d787327d72c2f449d9cef5d79223c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91460
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Commit 66518ead516e90d606e87c6ce58ec11fea6d172e
("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>
'CALLBACK_DOCUMENT_PASSWORD' needs to be handled
when opening a password-protected file, so don't
ignore it for the plain viewer case.
This makes a password prompt appear as expected
when trying to open a password-protected (encrypted)
file with Android Viewer, regardless of whether the
experimental editing option is enabled or not.
Change-Id: Ib7e969a53a484df3e2c7be1a0df4c81a48668045
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91228
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This also prevents some static analysis tool from
issuing a false positive that "The application uses
implicit intent that may be insecure under certain
conditions".
Change-Id: I1d4198b1c26c764c927d99c9a9e144da96ebc109
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90457
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... after commit 367431b6987b75e7a201499bfbd25a41c92a4a59
("tdf#126909 android: include icons into APK") had accidently
not only added the icon zip file to the 'assets/share/config' folder,
but also caused the assets mentioned below in build.gradle
to be copied there instead of the proper places, leading to
a crash when trying to access them.
(The problem did not show up in an incremental build, since "the
old copies" of the assets were still present where expected.)
Change-Id: I7d9cf89c399d6415ce97ac8af4a98610555c5f17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90344
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
While default build config for Android Viewer caused
the zip file(s) containing the icons to be built
(e.g. 'distro-configs/LibreOfficeAndroid.conf'
contains '--with-theme=colibre'), icons were not
included in the APK.
Do so now, which among others also makes page breaks
shown in Android Viewer (as requested in tdf#126909).
Change-Id: Ie16ff4b483287367b9f892ee614b3e5aa4d31820
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90330
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The previous version e.g. did not support building
Android App Bundles yet.
Drop explicit 'buildToolsVersion', as suggested in the warning
during build:
> WARNING: The specified Android SDK Build Tools version (27.0.3) is ignored,
> as it is below the minimum supported version (28.0.3) for Android Gradle
> Plugin 3.6.1.
> Android SDK Build Tools 28.0.3 will be used.
> To suppress this warning, remove "buildToolsVersion '27.0.3'" from your build.gradle
> file, as each version of the Android Gradle Plugin now has a default
> version of the build tools.
Change-Id: Iea5018366969fcefde1e9f4e8cb9836f5a09b41e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90099
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Missing escaping became apparent after a local
gradle update, after which the build failed with
> Android resource compilation failed
.../android/source/res/values-tr/strings.xml:231:5-73: AAPT: error: unescaped apostrophe in string
.../android/source/res/values-tr/strings.xml:231:5-73: AAPT: error: not a valid string.
.../android/source/build/intermediates/incremental/mergeStrippedUIReleaseResources/merged.dir/values-tr/values-tr.xml: AAPT: error: file failed to compile.
Change-Id: Iaffabfe82ce1a1255919e48dc15bd40ad89d1f90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90098
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This fits better than the "File Explorer Settings" one.
The whole "General" section was hidden before when editing
mode was disabled for the build ('!BuildConfig.ALLOW_EDITING').
Since the language setting is unrelated to this, no longer
do so, but explicitly remove the two other entries in this group,
namely "ENABLE_DEVELOPER" and "ENABLE_EXPERIMENTAL".
Change-Id: I64d1abef38d7669fc1072b380f497ca83e23f265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90096
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
UI file 'annotationmenu.ui' is needed to make documents with
comments work, rather than crashing Android Viewer.
This not just fixes the crash, but actually makes the
comments show up.
Change-Id: I68abc21f6d442549a8a8304d861e1c3223644fbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90094
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... in which case the handling of the previous three callbacks makes the
cursor (that can be used to do a manual selection) shown in addition
to the selection rectangle.
As a side note, the cursor previously shown in Calc was incorrect anyway
when doing a search, it was always at the top-left, and spanning nothing
(instead of the actual cell that was highlighted by the "selection rectangle").
In a quick test, this worked as expected in Writer with editing
capability enabled:
* when doing a search, the search result was highlighted, but no cursor
shown
* when long-tapping on a word, that word was highlighted and the cursor
was shown, allowing to adapt text selection as needed (e.g. to do
copy & paste in the next step).
Since the cursor is shown by handling the other callbacks, and it is just hidden
again, the cursor can still show up for a short moment before
being hidden again, but I see no easy way to avoid this, since
there seems to be no easy way to determine in the
'CALLBACK_TEXT_SELECTION{,_START,_END}' handling whether this
was called due to a search or some other event (like long-tapping on
a word in Writer with editing feature enabled).
Change-Id: I0ae85cd10b91582b2bd8ec9891bae5c832161710
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90093
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of "Enter" key that inserted a newline when clicked.
Instead, start a search in downward direction when the search button
is clicked, which makes using the search feature more intuitive.
I quickly tested with both, Writer and Calc.
Change-Id: Iffc9f6115e558721b34d8fb4ae2ed4a36c4a7aa5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90092
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The naming for the directions UP and DOWN were used the wrong way
around, which was also apparent when looking at
'android/source/res/layout/toolbar_bottom.xml', where icon
'"@drawable/ic_search_direction_down"' was assigned to the
button with ID "@+id/button_search_up" (and vice versa).
Adapt the naming to avoid confusion.
Change-Id: I5cf59f1789f2c12651ce6a5638d559658d9d4deb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90091
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
I cannot tell how to reproduce (how to open a file of "invalid type"?),
but had a crash with this stacktrace in adb log at some point
when testing various scenarios with the Android Viewer app.
It shows that no proper value was assigned for the resource ID,
leaving the default 0. Just don't set an icon in this case.
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: org.libreoffice, PID: 8749
E AndroidRuntime: android.content.res.Resources$NotFoundException: Resource ID #0x0
E AndroidRuntime: at android.content.res.ResourcesImpl.getValueForDensity(ResourcesImpl.java:246)
E AndroidRuntime: at android.content.res.Resources.getDrawableForDensity(Resources.java:905)
E AndroidRuntime: at android.content.res.Resources.getDrawable(Resources.java:845)
E AndroidRuntime: at android.content.Context.getDrawable(Context.java:687)
E AndroidRuntime: at android.support.v4.content.ContextCompat.getDrawable(ContextCompat.java:358)
E AndroidRuntime: at org.libreoffice.ui.RecentFilesAdapter.onBindViewHolder(RecentFilesAdapter.java:73)
E AndroidRuntime: at org.libreoffice.ui.RecentFilesAdapter.onBindViewHolder(RecentFilesAdapter.java:25)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Adapter.onBindViewHolder(RecyclerView.java:6673)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Adapter.bindViewHolder(RecyclerView.java:6714)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Recycler.tryBindViewHolderByDeadline(RecyclerView.java:5647)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline(RecyclerView.java:5913)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:5752)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:5748)
E AndroidRuntime: at android.support.v7.widget.LinearLayoutManager$LayoutState.next(LinearLayoutManager.java:2232)
E AndroidRuntime: at android.support.v7.widget.GridLayoutManager.layoutChunk(GridLayoutManager.java:556)
E AndroidRuntime: at android.support.v7.widget.LinearLayoutManager.fill(LinearLayoutManager.java:1519)
E AndroidRuntime: at android.support.v7.widget.LinearLayoutManager.onLayoutChildren(LinearLayoutManager.java:614)
E AndroidRuntime: at android.support.v7.widget.GridLayoutManager.onLayoutChildren(GridLayoutManager.java:170)
E AndroidRuntime: at android.support.v7.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:3812)
E AndroidRuntime: at android.support.v7.widget.RecyclerView.onMeasure(RecyclerView.java:3225)
[...]
Change-Id: I05594c3da26125a18be9226f290430aa9c7fa14c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90090
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This fixes as another crash with Android Viewer that
could (ocassionaly) be observed by
* open some ODT document
* press the "back button" while the document is still
being loaded
* repeat steps 1-2 until the crash occurs
Corresponding 'adb logcat' output:
I LibreOfficeMainActivity: onDestroy..
I LOKitTileProvider: Document destroyed: /storage/emulated/0/Download/simple.odt
D LOKitThread: mTileProvider==null when calling updatePartPageRectangles
D AndroidRuntime: Shutting down VM
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: org.libreoffice, PID: 9190
E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke interface method 'boolean org.libreoffice.TileProvider.isSpreadsheet()' on a null object reference
E AndroidRuntime: at org.libreoffice.LOKitThread.refresh(LOKitThread.java:159)
E AndroidRuntime: at org.libreoffice.LOKitThread.access$000(LOKitThread.java:26)
E AndroidRuntime: at org.libreoffice.LOKitThread$1.run(LOKitThread.java:239)
E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:883)
E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:100)
E AndroidRuntime: at android.os.Looper.loop(Looper.java:214)
E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7356)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
Change-Id: I9787a13b3485a87a133f8b5e4e03bbf3618fb2f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90089
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
'mTileProvider' can be null here, e.g. while loading the document.
This fixes a crash that could be reproduced e.g. by
* open a document
* press the "back button" while the document is still
being loaded
(Most easily reproducibly right after app installation, since
loading the first doc takes a very long time then.)
Relevant log messages from `adb logcat` output:
E AndroidRuntime: java.lang.RuntimeException: Unable to stop activity {org.libreoffice/org.libreoffice.LibreOfficeMainActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'void org.libreoffice.LOKitTileProvider.cacheDocument()' on a null object reference
E AndroidRuntime: at android.app.ActivityThread.callActivityOnStop(ActivityThread.java:4624)
E AndroidRuntime: at android.app.ActivityThread.performStopActivityInner(ActivityThread.java:4594)
E AndroidRuntime: at android.app.ActivityThread.handleStopActivity(ActivityThread.java:4669)
E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:233)
E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:201)
E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:173)
E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)
E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:107)
E AndroidRuntime: at android.os.Looper.loop(Looper.java:214)
E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7356)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
E AndroidRuntime: Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void org.libreoffice.LOKitTileProvider.cacheDocument()' on a null object reference
E AndroidRuntime: at org.libreoffice.LibreOfficeMainActivity.onStop(LibreOfficeMainActivity.java:427)
E AndroidRuntime: at android.app.Instrumentation.callActivityOnStop(Instrumentation.java:1466)
E AndroidRuntime: at android.app.Activity.performStop(Activity.java:8018)
E AndroidRuntime: at android.app.ActivityThread.callActivityOnStop(ActivityThread.java:4616)
E AndroidRuntime: ... 13 more
Change-Id: I9f8a9329801b721dbfbc0a49c150f88ec341059c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90088
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
'mViewportMetrics' can be null here, e.g. while the document is
still being loaded.
This fixes a crash that happened e.g. when tapping on the screen
while document was still being loaded.
Change-Id: Ib3f237ecf64c05a5736d97e00b46d0de2ef051a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90048
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
jurt.jar and unoil.jar are kept as effectively empty jars, each with a
Class-Path: ridl.jar
in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or
without also loading ridl.jar) will still have access to their content.
Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi)
are not part of the URE, but are now made available by URE's ridl.jar. This
should probably not cause problems in practice.
At least for now, we seal exactly those packages in ridl.jar that were
originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now,
but that would be mildly incompatible, as it would prevent 3rd-party code from
introducing additional UNOIDL entities in the relevant namespaces (even if that
is something we do not want 3rd-party code to do anyway).
However, some JunitTest_jurt_* define classes in those sealed packages. In the
past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt.
Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the
gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes
that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the
UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the
udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests
get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use
gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets
leave that for a follow-up clean up.)
As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/.
Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Instead of hard-coding the use of English as default
locale and allowing manually selecting another language,
this now makes the system's default locale to be used
by default in the Android Viewer. It's still possible to
explicitly select another language to override that.
In case there is no localization for the system locale,
an automatic fallback to English happens anyway, so there
should be no need to explicitly set the locale to English
in that case either.
Change-Id: I0b8cfafea6a4659c3657522cfd5895c00f25f054
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85583
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Previously, the call to 'ColorPaletteAdapter::setColorPalette' from
the 'ColorPickerAdapter' constructur (via 'initializeColorPalette')
would not just set the color palette, but also apply the color at
index (0, 0) to the current selection, since
'ColorPaleteAdapter::setPosition' calls
'colorPaletteListener.applyColor' after setting the position.
This is an undesirable side effect, and led to the situation described
in tdf#115698 that cell A1 would always get black background when
opening a spreadsheet in the Android viewer, since black is the color
at 'color_palette[0][0]' by default and cell A1 is explicitly selected
when Calc first opens, s. the 'CalcHeadersController' constructor.
For Writer, something similar could be reproduced by selecting a
word in a document using long-tap. If experimental editing mode was
enabled, that word got black background (other words selected
later didn't).
To avoid this, make 'ColorPaletteAdapter::setColorPalette' just set
the color palette and set back the values that indicate what is
selected but don't apply any color. (And make 'setColorPalette'
just take the palette as parameter, and set 0 for both start values,
as the only caller was doing as well).
Change-Id: I0fa720ac6550102701a2c82905c9720aab6daab2
Reviewed-on: https://gerrit.libreoffice.org/85044
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
The comment mentioning "Calc has a fixed zoom at 1x
and doesn't allow zooming for now" was there since
support for the Calc UI was added in commit
02f3c4848ab52358bfee56c570a19a3a071574f2 ("Calc UI
on Android Viewer") in 2017. That seems no longer to be
the case however, probably since commit
498dceb43f870bf9e380f1f87e99c6ccadf1963c
("sc lok: Implement hi-dpi and zoom for spreadsheets.").
Zooming in and out was working just fine when I tested this
with Android Viewer using a spreadsheet containing some text
and numbers, as well as a chart and an image.
Therefore, allow zooming for Calc as well.
Don't allow to set min zoom below the page width for Calc as
somewhat suggested by the existing comment ("applies to all
types of document; in the future spreadsheets may be
singled out"). I don't see a particular reason for this and
using 0f for minZoom would break double-tap zoom.
Change-Id: Ib08439edbbac59a00005213b533df5792da965ee
Reviewed-on: https://gerrit.libreoffice.org/84421
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
code reads a .ui file to show a menu to edit/delete that pagebreak. That
file was not packaged in the Android viewer and causes an exception that
is not handled and ultimately results in a crash.
Change-Id: Ie73d886daf9202ba12e1b5a241bc7b6d184ae770
Reviewed-on: https://gerrit.libreoffice.org/83104
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
There was a mismatch between the define DICT_JA_ZH_IN_DATAFILE (which
is effectively set for android as well via DISABLE_DYNLOADING in
i18npool/Library_i18npool.mk and the makefile rules to actually compile
the data files and set the DICT_JA_ZH_IN_DATAFILE define in other places
that were guarded by checks for iOS.
Change-Id: Ia0f117220ab3bad92093a3bf6c613aa9c4812ed4
Reviewed-on: https://gerrit.libreoffice.org/83102
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
when the user wildly switches documents in fast succession, mDocument
can be null - not creating a cache file definitely is better than a hard
crash....
Also onSaveInstanceState is meant for lightweight operations (e.g.
storing what file was openend and what position it was scrolled to), not
for backend-storing of data, so move creation of cache file to onStop
instead.
Change-Id: I2452ef24e309ea4a9594eb723e893798b9b47d98
Reviewed-on: https://gerrit.libreoffice.org/82774
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
typie is ArrayList<Float> - and code divides by/multiplies by zoom
factor later on, so won't keep whole numbers/changing remaining code to
Long would require rounding or reworking the rest of the code as well...
fallout from https://gerrit.libreoffice.org/#/c/82572/
Change-Id: I3f3c46c59f9a310bf48b8cb8b533fe51c9d6645e
Reviewed-on: https://gerrit.libreoffice.org/82775
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
This simplifies lots of logic in the clients, making it trivial to get
good row/column header alignment at any zoom. Ultimately TWIPS here are
highly misleading print-twips, and in this state are ~impossible to map
to pixels accurately unless all data is present back to the origin
(which is not the current approach).
Change-Id: I6ca30e77865b62e886e23860f7c23350e544c9fc
Reviewed-on: https://gerrit.libreoffice.org/82572
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
it is a bogus message and should have been "no such file or directory"
instead... license.txt wasn't shipped after the change to generate it
from xml/single-source.
Change-Id: I907a57ec359cf31ddc7967af2acd11ef3ff605eb
Just specify:
--with-android-ndk=$HOME/Android/Sdk/ndk-bundle
--with-android-sdk=$HOME/Android/Sdk
in your autogen.input, install the appropriate components via Android
Studio and you are done.
Change-Id: Ic99790b781b9017eb4e642380e230d6f7b49e9b7
Reviewed-on: https://gerrit.libreoffice.org/81228
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 246f1b5b4485b7db9f9584e4b3b819c87e331c0e)
Reviewed-on: https://gerrit.libreoffice.org/81328
Tested-by: Jenkins
support for targeting API 14 and 15 was removed in NDK 18, so set
minimum version to 16
mips support was removed in NDK 17
Clang now takes care about correct linking with libc++ shared or
static, so don't manually specify them anymore.
Same with __ANDROID_API_LEVEL__ define and the sysroot / isystem
handling, that is all covered by a single -target <triple><version>
simplifying things quite a bit.
also align ownloud sdk values with main build.gradle
Change-Id: Ib3ae4484e52214677e826270b731ecf7c5c15445
Reviewed-on: https://gerrit.libreoffice.org/77104
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Typically application should handle key press/release and multiple
actions. The onKeyPreIme may be used to handle some keys early and it's
not needed for writing text. And even if there would be a reason to use
it, then it should return true to notify that the event was handled
(otherwise we will get onKeyDown event for the same key).
Change-Id: I49ce7f411fac92ff86ca042a7f7467e910e46350
Reviewed-on: https://gerrit.libreoffice.org/66708
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
...to select the experimental ...Editing... Android build variant. (Ignored
for non-Android builds, but using libo_FUZZ_ARG_ENABLE anyway, just in case.)
Change-Id: I670925ff358039e38edc29db69f48a78d484f133
Reviewed-on: https://gerrit.libreoffice.org/65077
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
