| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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 ..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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].
|
