summaryrefslogtreecommitdiffstats
path: root/src/java/jogamp/android
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1123 - Android Launcher/ClassLoaderUtil: Fails to work w/ Android 5.* ↵Sven Gothel2015-01-281-0/+48
| | | | | | | | | | | | | | | | (lollipop/art) Our Android ClassLoaderUtil, used to daisy chain dex ClassLoader using GlueGen, Joal and Jogl APK files, doesn't work on Android 5.* (lollipop) with the art runtime. See below adb log. Seems like this is a known issue https://code.google.com/p/android/issues/detail?id=82122 Workaround mentioned is to copy the APK file(s) to a temp directory ..
* Code Clean-Up based on our Recommended Settings (jogamp-scripting ↵Sven Gothel2014-07-038-272/+272
| | | | | | | | | | | | | | | c47bc86ae2ee268a1f38c5580d11f93d7f8d6e74) Code Clean-Up based on our Recommended Settings (jogamp-scripting c47bc86ae2ee268a1f38c5580d11f93d7f8d6e74) - Change non static accesses to static members using declaring type - Change indirect accesses to static members to direct accesses (accesses through subtypes) - Add final modifier to private fields - Add final modifier to method parameters - Add final modifier to local variables - Remove unnecessary casts - Remove unnecessary '$NON-NLS$' tags - Remove trailing white spaces on all lines
* ActivityLauncher: Ensure System properties are cleared at stop() alreadySven Gothel2014-01-261-26/+36
|
* Android: Cleanup ClassLoaderUtil/LauncherUtil - Using cached parent ↵Sven Gothel2013-01-314-61/+153
| | | | | | | | | | | | | | | | | | | | | ClassLoader for SYS-Packages w/ native libs, and non cached child ClassLoader for USR-Packages Android's Dalvik VM, like a JVM, cannot load a native library from one location by multiple ClassLoader. Since we don't like to hardcode the system-packages, as it was before, i.e. "com.jogamp.common", "javax.media.opengl", we need to either copy the libs or use parenting of cached ClassLoader. The latter is chosen, since it's faster and uses less resources. - System-packages are passed through from the user 'List<String> LauncherUtil.BaseActivityLauncher::getSysPackages()' to the ActivityLauncher, which instantiates the ClassLoader. - No more hard-reference the system-packages in ClassLoaderUtil ("com.jogamp.common", "javax.media.opengl"), just use the new user provided system-packages. - The system-packages denominate a hash-key for caching, a new ClassLoader is created and mapped if it does not yet exist. - A non-chached user-packages ClassLoader is created using the cached system-packages ClassLoader as it's parent.
* Fix ActivityLauncher/MainLauncher .. and make adb-launch-main more suitableSven Gothel2013-01-192-25/+16
| | | | | | | | | | | | | | - ActivityLauncher - no finish() from onDestroy() - MainLauncher - finish activity after returning 'main()' returns - no finish() from onDestroy() - adb-launch-main: - Clear logcat - Wait until activity is stopped - Dump logcat to local logfile
* MainLauncher: Remove Thread.destroy() - n/a on Android ..Sven Gothel2013-01-191-1/+2
|
* Android Completion for launching main() class via MainLauncher; Fix ↵Sven Gothel2013-01-183-30/+92
| | | | | | | | | | | | | | ActivityLauncher order of delegation/super activity callbacks. - StaticContext: - Add ViewGroup for standalone tests w/ UI - MainLauncher/LauncherUtil: - Complete launching a main() class from our activity launcher - adding main-cmdline-args - ActivityLauncher - Fix order of delegation/super activity callbacks.
* Android Launcher: Fix ClassLoaderUtil's JNI lib-path determination, use ↵Sven Gothel2012-12-271-9/+19
| | | | | | | | | | | | ApplicationInfo's nativeLibraryDir (API level 9). On Android > 4.0.3 (maybe even earlier), w/ a split filesystem (internal and SDCARD) the JNI libs maybe stored at a different location than it's data path. ApplicationInfo's nativeLibraryDir properly determines the JNI storage location, hence use it. Prev. code also derived JNI lib path by the launcher's ApplicationInfo's nativeLibraryDir, which might be different than the user package's nativeLibraryDir. This is especially true, since the launcher may not hold any native libraries.
* Fix TempFileCache/LauncherTempFileCache (regression commit: ↵v2.0-rc9Sven Gothel2012-06-201-19/+32
| | | | | | | | | | | | | | | | | | | | 1468286bf569a493e4fdb887d5f3732f88c8cec3) 'update' scenario in same JVM instance. TempFileCache/LauncherTempFileCache were using the system property 'jnlp.jogamp.tmp.cache.root', if set. However, in case one JVM launched an old GlueGen (Applet) and then launching a new GlueGen (Applet) w/ a new tmpDir location, the property is still set but the tmpRootDir location does not exist. This patch tolerates this situation and cont. setting a new tmpRootDir. Example: JVM1.GlueGen1 tmpDir: /tmp/, tmpRootDir: /tmp/jogamp.tmp.cache_000000/ JVM1.GlueGen2 tmpDir: /tmp/jogamp_0000/, tmpRootDir: /tmp/jogamp_0000/file_cache/ Misc: - IOUtil: Always use 'jogamp_xxxx' as the sys-temp subfolder for tmpDir - JNILibLoaderBase: Remove unised import - TempJarCache.validateCertificates(): Add OK DEBUG output.
* Fix Bug 587: Use alternative storage location if platform's temp directory ↵Sven Gothel2012-06-161-3/+4
| | | | | | | | | | | | | | | | | | | | | is mounted w/ noexec ; IOUtil API change! Test whether executable files can be launched in temporary folder by trying to run an empty executable file - if !( WINDOWS | OPENKODE ) TempDir: 1) ${java.io.tmpdir}/jogamp 2) $XDG_CACHE_HOME/jogamp - if !( ANDROID | MACOS | WINDOWS | OPENKODE ) 3) $HOME/.jogamp $XDG_CACHE_HOME defaults to $HOME/.cache - TempFileCache: ${TempDir}/file_cache -> ${java.io.tmpdir}/jogamp/file_cache - LauncherTempFileCache: ${TempDir}/file_cache -> ${java.io.tmpdir}/jogamp/file_cache +++ AndroidUtils*.getTempRoot(): Remove unused AccessControlContext param
* Android AssetDexClassLoader: Disable DEBUG flag.Sven Gothel2012-05-041-1/+1
|
* LauncherUtil: Allow no query in URI and no PKG in querySven Gothel2012-05-041-4/+1
|
* Android: Add the LauncherVersionActivity ..Sven Gothel2012-05-041-0/+92
|
* Android ClassLoaderUtil: Cleanup hack ..Sven Gothel2012-05-041-2/+0
|
* Android Launcher: More verbose ClassLoader*Sven Gothel2012-05-032-4/+30
|
* AndroidLauncher: Add 'MainLauncher'; ClassLoaderUtil adds list of direct ↵Sven Gothel2012-05-034-99/+295
| | | | | | | | | | APKs to add to classpath MainLauncher is capable of launching a traditional static main method from a activity. TODO: - parametrize the APK list (junit, ..) - pass-through the activity instance to be used w/ NEWT AndroidWindow
* StringBuffer -> StringBuilder (Local objects, no concurrency)Sven Gothel2012-04-161-1/+1
|
* ActivityLauncher/LauncherUtil: Clear properties 'onDestroy()'Sven Gothel2012-04-092-4/+18
|
* Add 'asset' URLConnection; IOUtil uses URLConnection / incr. effeciency; ↵Sven Gothel2012-03-175-79/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Android: New ActivityLauncher (jogamp.android-launcher.apk)Sven Gothel2012-03-145-0/+1284
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].