Age | Commit message (Collapse) | Author |
|
Change-Id: Ie0d7bd95207aafb269f23974b8e90fa0b50fdb86
|
|
Change-Id: I4aee6214123b14f40e01850e1814a4e2d089ec8c
|
|
Change-Id: I6ef47a04c6628723a433bbb625b0934979bd6725
|
|
Change-Id: I66e97d73c410ac6f2e481ba9b2b22183f57438bd
|
|
Serialize the Ant cleaning and building of android/abs-lib so that one
Ant is not cleaning it while another is building something that
depends on it.
Change-Id: I22fde47bf84208fa129b8f6a65a2314c885451a0
|
|
Change-Id: Icf77936c4307f816e85cb840d650a4c958a15995
|
|
Change-Id: I0bb98a9842003973ad50f227961ac00197f85bf2
|
|
|
|
Try to start consolidating the complexity here.
generate Application.mk to specify the required ABI
fold common distro-config pieces out of README
|
|
|
|
Change-Id: Id2aa869f05b09dc22676d63390ec10bf575571ef
|
|
Render directly to a direct ByteBuffer allocated on the Java side.
Change-Id: I2d66e4146df77e92260918a78ef22cd9b8c95384
|
|
Modify DocumentLoader correspondingly. Take Android bug 32588 into
account.
Ideal would be to extend the XDevice stuff, or something, so that one
could hand it a pre-allocated RGBA buffer into which the
drawing/rendering would go. Then one could get rid of the silly
convert-to-BMP phase, which prefixes the bitmap data with BMP and DIB
headers (and thus, I guess, has to copy and allocate another
copy). Will see.
Change-Id: I4597cd933db8faa8105dc8f19638d712d5d2238a
|
|
Change-Id: Iafa2c1805eea2f521479dc97d5668d82b1c91bef
|
|
Change-Id: I8f99399faa3b0762bdea2aac09f1b849639cd191
|
|
Change-Id: I41900eca9a46acbd2f1dfac98fcfc73a62acc150
|
|
|
|
Remove now redundant FONTCONFIG cmdline arguments, and add fallbacks
for not having cmdline arguments in the intent when launching.
|
|
|
|
Remove now redundant FONTCONFIG cmdline arguments, and add fallbacks
for not having cmdline arguments in the intent when launching.
|
|
Change-Id: Ic87be0146360c5e32f1f12f255c897e051c9a50c
|
|
Change-Id: I45732ac81d00837ce517ed5c527c8c767e690abf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sorry for the large unstructured commit. But hey, the Android code is
experimental so far.
Extract the native lo-bootstrap code into a fairly normal library
built in sal. (Previously it was the JNI part of the "Bootstrap" app.)
Just linkink normally to liblo-bootstrap from C++ code that uses it
works fine, no need to do a dlsym lookup.
Bootstrap is still a subclass of NativeActivity and can thus still be
used as an "app" (to start unit tests, or whatever), but can also be
used from some other app's Java code to just get access to the
lo-bootstrap native methods.
Introduce a new top-level "module", android, for Bootstrap and the
experiments with DocumentLoader.
Note that the experimental DocumentLoader app still crashes. It can't
create the com.sun.star.frame.Desktop instance.
I spent lots of time debugging in the painfully inadequate
ndk-gdb. (Even the newer gdb build from the "mingw-and-ndk" project is
quite crappy in many ways.) I should really experiment with
corresponding code on a normal platform first before even trying on
Android. Basically, I think that if I just can get the concept of Java
code that instantiates and uses LO components *in-process* working on
a normal desktop platform, it should work on Android, too.
|