We don't build/ship API-13 for any other assemblies, so this just wastes build time for something that'll never be used.
…it was previously invoked.
The current -path value passed to find will ignore all the APIs older than 16. The addon path format used before 16 is addon-google_apis-google_inc_-X while with 16 and up it is addon-google_apis-google-X The patch uses -regex instead of -path to cope with the above.
Mwa-ha-ha-ha-ha *cough* *splutter* We've shipped Mono.Android.GoogleMaps.dll, Mono.Android.Support.v4.dll, and Mono.Android.Support.v13.dll since close to the launch of Mono for Android. There's just one current problem with them: they're old. Mono.Android.GoogleMaps.dll bound the maps.jar addon, which is no longer distributed anymore, and it's no longer possible to obtain certificates to use the library. It's dead. It's replacement is the Google Play Services library, and the corresponding Component: http://components.xamarin.com/view/googleplayservices Mono.Android.Support*.dll are in a slightly different boat: They at least still exist in a (mostly) similar form. The problem is that the underlying Java library appeared to break backward compatibility  awhile ago, preventing us from easily updating the assembly, and we now have the Component to take their places, which are considerably more up to date and have gotten FAR more work: http://components.xamarin.com/view/xamandroidsupportv4-18 http://components.xamarin.com/view/xamandroidsupportv13-18 TL;DR: We're obsoleting these assemblies so that we can remove them in a future Xamarin.Android release, and direct people to use the newer, and considerably better, alternatives. : This is on memory, but at the time the support library contained types with platform names, like JellyBeanSomethingOrOther, and these had "disappeared" after the update. In retrospect, it seems that Google changed the support lib from being "just" a .jar to being a core .jar + Source code, and many of the missing types were now available as source. This was in a cruch time, so the "retrospect" didn't occur until months later, by which time the Xamarin Component replacement existed and was using a newer version of the library. We have enough maintenance work with the core; we more than happy to have the Components team take over these bindings.
Now google components have directory name like addon-google_apis-google-19-1 (extra -1 part) and it causes build breakage. So take that part in our `find` regex.
…nings. The interface in the error message below exists only after API Level 18. [jar2xml] -jar "/svn/monodroid/monodroid/out/lib/mandroid/jar2xml.jar" --out="obj/platform-4/generated-api.xml" --jar="/home/atsushi/android-sdk-linux/extras/android/support/v4/android-support-v4.jar" --ref="/home/atsushi/android-sdk-linux/platforms/android-17/android.jar" --droiddocpath="/home/atsushi/android-sdk-linux/docs/reference" java.lang.NoClassDefFoundError: android/view/ViewTreeObserver$OnWindowAttachListener at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at jar2xml.JavaArchive.getPackages(JavaArchive.java:86) at jar2xml.JavaArchive.getPackages(JavaArchive.java:64) at jar2xml.Start.main(Start.java:126)
…d from generic type and exposes collection).
…ic API yet break build.
From Android SDK docs, not by external page (doesn't work anyways). Add some transient members to those API compatibility breakers. Reference android-17/android.jar for *every* API level to generate bindings. support-v*.jar internally references those types, causing some class loader crashes, while they are not referenced in public API anyways.
This reverts commit fdc5dba. While compatibility-v13 can't be built for an "aribtrary" API level, it _can_ (and should!) be built against API levels 14+ Ensuring that we only build for API 14+ is handled by the "caller" of this Makefile.
OverlayItem.GetMarker(ItemState) and MapActivity.OnGetMapDataSource() weren't bound because they used enum types that didn't exist. (Oops.) Reported by: Goncalo Oliveira http://lists.ximian.com/pipermail/monodroid/2012-November/012759.html
The problem: Installing the API 16 Google Addons SDK causes the build to break (!). Why? Because the e.g. API 4 adds path is: add-ons/addon-google_apis-google_inc_-4 while the API 16 path is: add-ons/addon-google_apis-google-16 No problem, right? Wrong: JARS = $(shell find $(ANDROID_SDK_PATH)/ -name maps.jar) ADDONDIRS = $(patsubst %/libs/maps.jar,%,$(JARS)) ADDONDIR = $(shell echo $(firstword $(ADDONDIRS)) | sed -e 's/^\(.*-\).*$$/\1/') $(JARS) contains every maps.jar within the Android SDK, no problem. $(ADDONDIRS) contains all add-ons/addon-* directories which eventually contain a maps.jar file; no problem. The problem is $(ADDONDIR), which assumes that every such add-ons/addon-* directory has a common prefix, with the only difference being the API number. This is NO LONGER the case. Due to path lookup ordering, $(ADDONDIRS) contained: add-ons/addon-google_apis-google-16 add-ons/addon-google_apis-google_inc_-4 i.e. API 16 was first, so when we tried to generate the API 4 description, we tried to find add-ons/addon-google_apis-google-4, which doesn't exist. Doh! The solution? Fuck that shit; `find` FOUND a maps.jar to use. Don't look for a common directory name prefix, just use the FOUND NAME. This does mean that we can't use $(JARS) as a dependency (we're only going to find what's installed), so we use an explicit file check instead.
If $ANDROID_SDK_PATH is a symlink, then `find $(ANDROID_SDK_PATH)` finds only $ANDROID_SDK_PATH and no files underneath it. To traverse the symlink target, we need to `find $(ANDROID_SDK_PATH)/` (note trailing slash).
(More of a "this is how things _could_ be done" rather than "how things _should_ be done", as the scenario outlined below isn't actually the case with the Google Maps API.) Imagine you have a Java library which changes over time, like, oh, android.jar. ;-) The problem: using `mcw-gen build` will result in an assembly which matches the source .jar 1:1 (module some "niceness" changes -- added events, etc.). This means that if a member _moves_ between .jar versions, you can't necessarily use an assembly built on version N+1 on a platform that only provides version N ("the MotionEvent issue"). Which brings us to `mcw-gen merge`, new to Mono for Android 4.1.1. This allows "merging" API descriptions so that instead of having an API description which is a 1:1 representation of the underlying .jar, it is instead the union of the types and mebers across versions. If a method is moved into an introduced base class, the merged API will contain both the introduced base class + method AND the "original" member. This allows an assembly binding N+1 to reference the "original" and execute sanely on a platform that has version N (as long as you don't access members that only exist in version N+1). Generating such a merged assembly requires 4 steps: 1. Generate the 1:1 API description for all desired versions, e.g. maps.jar v8 requires descriptions for v4, v7, and v8. 2. Merge these API descriptions into a single description: mcw-gen merge -o merged.xml source1.xml source2.xml ... 3. Generate sources based on the merged XML mcw-gen bind -i merged.xml -o dir .. 4. Compile the sources: smcs -t:library -out:binding.dll dir/src/generated/*.cs ...
…ides to change it