| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'android-armv7hf' and 'linux-armv7hf' ]
- Platform gets new ABIType [ GENERIC, ARMEL, ARMHF ]
- Platform impl. needs to guess ABIType in case of ARM,
since no Java system property ('os.arch' ..) reflects the new EABI.
I consider this a bug, since this will also hinder JNLP to work.
The latter also uses 'os.arch' sys property to determine the nativelib resource!
(See Platform.guessABITypeImpl(..) for details how we guess the type.)
- Adding symbolic links to ubuntu's gnueabihf cross tool chain
- Adding armhf crossbuild script
|
| |
|
|
|
|
| |
/ API doc cleanup; DynamicLibraryBundle: Add getDefaultRunnableExecutor()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Fix 'NIOOnly' impl
- Use 'final' in gen. Java stubs ;
- No null check for Buffers.isDirect(arrayArg) [required]
- Clarify Buffer arg API doc (NIOOnly or NIODirectOnly)
- cleaned up loop / branch (CMethodBindingEmitter)
- remove unsued vars/code
- Tests:
- covers normal/NIOOnly/NIODirectOnly
- covers passing null for array and NIO
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android ClassLoaderUtil cleanup;
- Add 'asset' URLConnection
- Please read API doc 'PiggybackURLConnection' and 'AssetURLConnection'
- Solves generic resource handling where platform locations may differ,
ie ClassLoader lookup on Android in the 'assets/' subfolder.
- New Android 'AssetDexClassLoader' uses 'assets/' folder for findResource(..)
- aapt.signed (our APK ant task)
- uses 'assets/' folder
- adds the 'assetsdir' attribute allowing to copy other assets into the APK
- IOUtil uses URLConnection / incr. effeciency
- using URLConnection on all getResource(..) since URL
is connected anyways for validation and URLConnection can be used by caller right away
- String getRelativeOf(URL, String) -> URL getRelativeOf(URL, String)
- preserves scheme, authority, etc
- simple parentOf handling, more efficient
- reusing new 'asset' protocol impl.
- Android ClassLoaderUtil cleanup;
- Use createClassLoader(..) impl for build-in static jogamp and user APKs,
which removes code redundancy
Tests: New code path, especially 'assets' are covered by new unit tests, no regressions on Linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ActivityLauncher provides delegating Activities, allowing the user to:
- daisy chain custom APK classes and native libraries to the classpath
- name one custom activity which gets delegated to, the downstream activity
Overview:
[User:a1] -- (usr-data) --> [Launcher] -> [User:a2] + using [other packages..]
[User APK] - The user provided APK
[JogAmp APK] - JogAmp APKs
[User:a1] - The initial user activity, which starts the [Launcher].
Providing data to [Launcher]: [User:a2], [User APK]
Resides in [User APK]
[User:a2] - The actual downstream 'real' activity, spoiled w/ full fledged ClassLoader
having access to all packages as requested, ie. [User APK], ..
Resides in [User APK]
[Launcher] - The launcher activity.
Gets called by [User:a1].
Creates a new ClassLoader, daisy chainging all requested APKs.
Instantiates [User:a2] w/ new ClassLoader.
Delegates all calls to [User:a2].
Resides in [JogAmp APK].
|
| |
|
|
|
|
| |
gluegen-cpptasks-base.xml in custom files w/ gluegen.root.abs-path.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
explicit BOOTCLASSPATH, use default.
(2) Android 4.0.3 LEB 12.02 / Pandaboard requires the original BOOTCLASSPATH,
otherwise dependencies are broken and dalvikvm crashes.
Adding 'our' ant-junit-all.apk to 'complete' the set of our required junit/ant classes
seems to work well on V. 2.3.6 (Samsung Galaxy S) and V. 4.0.3.
|
|
|
|
|
|
|
|
| |
target which makes it self-contained
build script and jenkins-node startup-script solely use env-vars.
Remove env. TARGET_ARCH, which was same as TARGET_TRIPPLE.
|
|
|
|
|
|
| |
-> JarURL on Android
All [remaining] tests passed on Android!
|
|
|
|
| |
most of tests in TestJarUtil
|
|
|
|
|
|
|
| |
from build.xml -> gluegen-cpptasks-base.xml
- unifies definition
- echo values
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remote test fix:
- run targetcommand w/ explicit root via 'su'
- rsync: more excludes, only use '-rt'
- explicit chmod 644 on results
- adb commands include naming of remote machine: -s ${env.TARGET_IP}:${env.TARGET_ADB_PORT}
GlueGen-cpptasks-android-armv7:
- use unique project name (warning)
- gcc +
-fpic
-D__unix__
- ld +
-fpic
-nostdlib
-Bdynamic
-Wl,-dynamic-linker,/system/bin/linker
-Wl,-z,nocopyreloc
explicit add 'dl' to list of libs
|
| |
|
|
|
|
| |
clarification
|
|
|
|
| |
android-ndk (sym-link)
|
|
|
|
| |
Including Edwin Vane's work in commit d51d2aaad01d1c8188193a7913c6ef0fc38ea798
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- A bug in cpptasks was getting in the way of a working build with NDK
r7. A local patch to cpptasks fixed the bug.
- The patch is added as make/lib/cpptasks_gcclinker.patch and applies
cleanly to cpptasts @ revision 177.
- The result of building cpptasks r177 with this patch is part of the
commit as well.
- Cleaned up and simplified the android cross-compile script in
make/scripts.
- Cleaned up arguments passed to gcc for compiling and linking to look
more like the command lines used for building NDK samples.
- Some differences are necessary as cpptasks won't let us specify any
binary other than 'gcc' for building. See
gluegen-cpptasks-android-armv7.xml for comments on the matter.
- Thinking forward to x86 support, generalized jogamp-androidtasks.xml
to install the gluegen shared library in a subdirectory of image/lib
named for the targetted ABI for packaging with aapt. This file is
no-longer ARM-specific.
|
|/ |
|
| |
|
|
|
|
| |
failure.
|
|
|
|
| |
otherwise the jenkins build fails.
|
|
|
|
| |
JUNIT_DISABLED -> junit.is.disabled
|
| |
|
|
|
|
| |
location
|
| |
|
|
|
|
| |
proper path for jenkins builds
|
| |
|
|
|
|
|
|
| |
gluegen-cpptasks-linux-armv7.xml
Env: GLUEGEN_CPPTASKS_FILE -> property: gluegen-cpptasks.file
|
|
|
|
| |
'gluegen.cpptasks.detected.os' is set.
|
|
|
|
|
|
|
|
|
|
|
| |
grained controll of test behavior.
Environment vars, mapped to properties:
JUNIT_RUN_ARG0 -> junit.run.arg0
JUNIT_RUN_ARG1 -> junit.run.arg1
This allows us to disable ScreenMode on Linux-ARM-Omap4 for example,
where XRandR calls consume up to 3s per test.
|
| |
|
| |
|
|
|
|
| |
196c325aa3dddb0d775e8fb80e26333208fe6c7e) - generalize env. TARGET_JAVA_LIBS
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current minimum requirements are:
- Java 1.6 (Level 6.0)
- Android SDK API Level 9 (Version 2.3 Gingerbread)
Official production builds are performed w/ Java 1.6.
- Java 1.6 (Level 6.0)
- Android SDK API Level 9 (Version 2.3 Gingerbread)
Android supports Java language level 6.0.
Nevertheless, it cannot be guaranteed whether the Android API
supports all classes and methods of Java 1.6.
It is required for JogAmp developers to validate Android compatibility
by an Android crosscompilation build.
Current GlueGen code utilizes some minor Java 1.6 features
which could be replaced, however it's not desired at this point
since we have no mode hard Java 1.5 constraints.
Notes:
- On OS X 10.5.8, only the 64bit version of Java6 is available
and hence the only supported one on Leopard.
+++
Pushing determination of host (compiletime) and target (runtime) Java version
to 'jogamp-env.xml'.
jogamp-env.xml uses:
env: SOURCE_LEVEL -> propery: target.sourcelevel def.: ${ant.java.version} >=1.6 (!)
env: TARGET_LEVEL -> propery: target.targetlevel def.: ${ant.java.version} >=1.6 (!)
env: TARGET_RT_JAR -> propery: target.rt.jar def.: ${java.home}/lib/rt.jar
Either all above values are set, or none at all (default),
otherwise a build error is being thrown.
Further more we have the compiletime properties:
host.sourcelevel def.: ${ant.java.version} >= 1.6 (!)
host.targetlevel def.: ${ant.java.version} >= 1.6 (!)
host.rt.jar def.: ${java.home}/lib/rt.jar
+++
- 'javac.memorymax' defaults to 1024m now.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
weakly binding
Removed 'prebind' auto option, since OS X dyld performs better w/o since 10.5 (?)
Allowing linker options for weakly fraemwork/library binding
"-weak_framework", "-lazy_framework", "-weak_library"
which is required if linked for 10.5, allowing unresolved references.
|
|
|
|
| |
Platform.loadGlueGenRTImpl(), Reuse JarUtil (same methodology) to determine whether we run from JarURL
|