Android-specific notes Note that this document has not necessarily been updated to match reality... * Getting something running on an emulated device Create an AVD in the android UI, don't even try to get the data partition size right in the GUI, that is doomed to producing and AVD that doesn't work. Instead start it from the console: LD_LIBRARY_PATH=$(pwd)/lib emulator-arm -avd -partition-size 500 In order to have proper acceleration, you need the 32-bit libGL.so: sudo zypper in Mesa-libGL-devel-32bit Where is the literal name of the AVD that you entered. Then: make cmd cmd=bash cd android/qa/sc make clean all install make run ; adb shell logcat And if all goes well - you should have some nice unit test output to enjoy. After a while of this loop you might find that you have lost a lot of space on your emulator's or device's /data volume. If using the emulator, you can do: adb shell stop; adb shell start but on a (non-rooted) device you probably just need to reboot it. On the other hand, this phenomenon might not happen on actual devices. and continue onwards & upwards. * What about using a real device? That works fine, too. You won't be able to use the "adb shell stop" and "adb shell start" commands to do anything, as far as I know. But don't seem to be necessary on a real device anyway? * Debugging Debugging is fun, the default NDK gdb (in v7) is busted, you need to download a new one from: http://code.google.com/p/mingw-and-ndk/ Even this 'fixed' gdb is broken in the way that it can see symbols only for shlibs that were already loaded when the debuggee was attached, so you need to carefully guess where to put: fprintf(stderr, "Sleeping NOW!\n"); ::sleep(20); into the code; and when you see that in logcat, you have time to run: ndk-gdb and it will attach the process. thread 12 # or perhaps 13 backtrace may show you the native code trace. In r8b the ndk-gdb seems to work a bit better, and I think it isn't necessary to use the mingw-and-ndk ndb-gdb any longer. * Common Errors / Gotchas lo_dlneeds: Could not read ELF header of /data/data/org.libreoffice...libfoo.so This (most likely) means that the install quietly failed, and that the file is truncated; check it out with adb shell ls -l /data/data/.... * Detailed explanation Unit tests are the first thing we want to run on Android, to get some idea how well, if at all, the basic LO libraraies work. We want to build even unit tests as normal Android apps, i.e. packaged as .apk files, so that they run in a sandboxed environment like that of whatever eventual end-user Android apps there will be that use LO code. Sure, we could quite easily build unit tests as plain Linux executables (built against the Android libraries, of course, not GNU/Linux ones), push them to the device or emulator with adb and run them from adb shell, but that would not be a good test as the environment such processs run in is completely different from that in which real end-user apps with GUI etc run. We have no intent to require LibreOffice code to be used only on "rooted" devices etc. All Android apps are basically Java programs. They run "in" a Dalvik virtual machine. Yes, you can also have apps where all *your* code is native code, written in a compiled language like C or C++. But also also such apps are actually started by system-provided Java bootstrapping code (NativeActivity) running in a Dalvik VM. Such a native app (or actually, "activity") is not built as a executable program, but as a shared object. The Java NativeActivity bootstrapper loads that shared object with dlopen. Anyway, our current "experimental" apps (DocumentLoader and LibreOffice4Android) are not based on NativeActivity any more. They have normal Java code for the activity, and just call out to native libraries to do all the heavy lifting. It is somewhat problematic to construct .apk packages except by using the high-level tools in the Android SDK. At least I haven't figured out how to manually construct an .apk that is properly signed so that it will run in the emulator. (I don't have any Android device...) I only know how to let the SDK Ant tooling do it... At this stage, the plan is that a LO Android app will work would something like this: We have a Java class org.libreoffice.android.Bootstrap that that loads a small helper native library liblo-bootstrap.so that implements JNI wrappers for dlopen(), dlsym(), and ELF header scanning coresponding to looking for DT_NEEDED entries with readelf. The Java code then loads the actual native library that corresponds to the LibreOffice-related "program" we want to run. For unit tests, a library that corresponds to cppunittester program. Then through helper functions in liblo-bootstrap it calls a named function in that "program". This Android-specific native code (the lo-bootstrap library) is for now in sal/android, and the Java code in the android "module" (subdirectory right here). option> LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/postprocess
AgeCommit message (Expand)Author
2013-10-18fdo#60698: Move fileaccess module to ucbMarcos Paulo de Souza
2013-10-14fdo#61950 De-extensionize presentation minimizerDavid Ostrovsky
2013-10-08oglcanvas: ship comp registration, return device window.Thorsten Behrens
2013-10-02fix path to .xcu files in --enable-online-update buildMatúš Kukan
2013-10-02gbuild: kill gb_XcsTarget_get_outdir_targetMatúš Kukan
2013-10-02gbuild: kill gb_XcuModuleTarget_get_outdir_targetMatúš Kukan
2013-10-02gbuild: kill gb_XcuDataTarget_get_outdir_targetMatúš Kukan
2013-10-02gbuild: kill gb_XcuLangpackTarget_get_outdir_targetMatúš Kukan
2013-10-02lingucomponent: kill Package_config.mkMatúš Kukan
2013-10-02sdext: kill Package_pdfimport_xcu.mkMatúš Kukan
2013-10-02use full path in postprocess_FILES_fooMatúš Kukan
2013-10-02we do not need .xcd files in solverMatúš Kukan
2013-10-01remove run-time replacement of %WRITERCOMPATIBILITYVERSIONOOO11Michael Stahl
2013-09-24Create a proper Info.plist for the OS X app bundle already in configureTor Lillqvist
2013-09-23Try to fix cross-compilationTor Lillqvist
2013-09-12gbuild: remove gb_Rdb__get_final_targetMichael Stahl
2013-09-12typoThomas Arnhold
2013-09-11Towards a working instdir for Mac OS XStephan Bergmann
2013-09-09start to use instdir for subsequentcheck tests; avoid make dev-installMatúš Kukan
2013-09-09gbuild: install rdb files directly in module they come fromMatúš Kukan
2013-09-09change PRODUCTNAME for --enable-dbgutil buildMichael Stahl
2013-09-09replace variables in main.xcd already in gbuildMatúš Kukan
2013-09-09install images with filelistsMatúš Kukan
2013-09-08break the habit of throwing away the actually useful error messagesChristian Lohmaier
2013-09-02GSOC work, config crach fixGergo Mocsi
2013-08-30ENABLE_LOCKDOWN Harmonize ENABLE_* variable to TRUE/<nothing>Norbert Thiebaud
2013-08-30ENABLE_NPAPI_* Harmonize ENABLE_* variable to TRUE/<nothing>Norbert Thiebaud
2013-08-28Last piece of SOLAR_JAVA to ENABLE_JAVA migration.Andrzej J.R. Hunt
2013-08-22remove superfluous sort.plBjoern Michaelsen
2013-08-22mork and mozab only on DESKTOPTor Lillqvist
2013-08-21fix connectivity bits in postprocessBjoern Michaelsen
2013-08-19Rename SOLAR_JAVA to ENABLE_JAVA and HAVE_FEATURE_JAVATor Lillqvist
2013-08-18Further work on the "Mac-like app structure" optionTor Lillqvist
2013-07-26trivial build fix.Michael Meeks
2013-07-26initial vlc component build / conditionals and hookup.Michael Meeks
2013-07-23it is not possible to sign libs that are in useDavid Tardon
2013-07-22Probably no reason to filter out these for iOS any moreTor Lillqvist
2013-07-18fdo#65761 yet another gbuildification bugDavid Ostrovsky
2013-07-16Make firebird-sdbc install consistent with other drivers.Andrzej J.R. Hunt
2013-07-16Firebird: initial implementation of the skeleton driver.Javier Fernandez
2013-07-05Missing slash that prevents windows signingFridrich Štrba
2013-07-03OOpsFridrich Štrba
2013-07-03Fix Windows signing and timestampingFridrich Štrba