Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on May 2, 2014
  1. @jonpryor

    Don't build Mono.Android.GoogleMaps.dll for API-13.

    jonpryor committed
    We don't build/ship API-13 for any other assemblies, so this just
    wastes build time for something that'll never be used.
Commits on Apr 29, 2014
  1. @vargaz

    Really fix the previous change.

    vargaz committed
  2. @vargaz

    Fix the previous change.

    vargaz committed
  3. @vargaz
  4. @vargaz
  5. @vargaz

    Get rid of get-maps.jar-path and do its work in the shell code where …

    vargaz committed
    …it was previously invoked.
Commits on Apr 28, 2014
  1. @grendello

    Merge pull request #3 from mono/fix-maps-build

    grendello committed
    Fix finding the maps.jar archive
  2. @grendello

    Fix finding the maps.jar archive

    grendello committed
    The current -path value passed to find will ignore all the APIs older than 16. The addon path
    format used before 16 is
    while with 16 and up it is
    The patch uses -regex instead of -path to cope with the above.
Commits on Apr 14, 2014
  1. @atsushieno
  2. @atsushieno
Commits on Apr 8, 2014
  1. @jonpryor


    jonpryor committed
    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:

    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 [0] 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:

    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.
    [0]: 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.
Commits on Apr 2, 2014
  1. @atsushieno

    Fix path capture in `find` for google maps component.

    atsushieno committed
    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.
Commits on Feb 20, 2014
  1. @atsushieno

    Specify the latest android platform to eliminate extraneous build war…

    atsushieno committed
    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(
    	at Method)
    	at java.lang.ClassLoader.loadClass(
    	at java.lang.ClassLoader.loadClass(
    	at jar2xml.JavaArchive.getPackages(
    	at jar2xml.JavaArchive.getPackages(
    	at jar2xml.Start.main(
Commits on Jan 9, 2014
  1. @atsushieno
Commits on Nov 1, 2013
  1. @atsushieno

    Remove not-supported API so far (non-instantiated generic type derive…

    atsushieno committed
    …d from generic type and exposes collection).
Commits on Jul 30, 2013
  1. @jonpryor

    Fix member compatibility in DrawerLayout, SlidingPaneLayout.

    jonpryor committed
    Commit 91f7d82 is great from a usability perspective, as EventArgs
    subclasses would have usable members, e.g. SlideOffset instead of P0.
    Unfortunately, this also breaks compatibility.
    Commit 91f7d82 fixed many of the incompatibilities, but we've found
    others that need fixing.
Commits on Jul 24, 2013
  1. @atsushieno
Commits on Jun 27, 2013
  1. @atsushieno

    Give parameter names to support library bindings.

    atsushieno committed
    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.
Commits on Nov 30, 2012
  1. @jonpryor

    Revert "compatibility-v13 cannot be built for arbitrary API level."

    jonpryor committed
    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.
Commits on Nov 8, 2012
  1. @atsushieno

    hush mdoc.

    atsushieno committed
Commits on Nov 2, 2012
  1. @jonpryor

    [GoogleMaps] Fix enum types.

    jonpryor committed
    OverlayItem.GetMarker(ItemState) and MapActivity.OnGetMapDataSource()
    weren't bound because they used enum types that didn't exist. (Oops.)
    Reported by: Goncalo Oliveira
Commits on Aug 31, 2012
  1. @atsushieno
Commits on Jul 12, 2012
  1. @jonpryor

    [GoogleMaps] Rework maps.jar resolution.

    jonpryor committed
    The problem: Installing the API 16 Google Addons SDK causes the build
    to break (!). Why? Because the e.g. API 4 adds path is:
    while the API 16 path is:
    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:
    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.
    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.
Commits on Jun 5, 2012
  1. @atsushieno
Commits on Apr 17, 2012
  1. @jpobst
Commits on Apr 16, 2012
  1. @shana
  2. @shana

    Fix maps.jar path

    shana committed
Commits on Apr 13, 2012
  1. @jonpryor

    [GoogleMaps] Support ANDROID_SDK_PATH being a symlink.

    jonpryor committed
    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).
  2. @jonpryor

    [Mono.Android.GoogleMaps] Generate merged API assemblies.

    jonpryor committed
    (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"
    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 ...
  3. @jonpryor

    Revert support for "any" API level

    jonpryor committed
    Revert commit 0419ac5; we're doing "any" support differently.
Commits on Apr 10, 2012
  1. @shana
Commits on Apr 4, 2012
  1. @jonpryor

    [GoogleMaps] Add support for "any" API level.

    jonpryor committed
    The "any" API level needs to be mapped to the $(API_ANY_LEVEL) level,
    as it's not a Google-defined Android API level.
Commits on Mar 15, 2012
  1. @jpobst
Commits on Mar 5, 2012
  1. @atsushieno
Commits on Mar 2, 2012
  1. @jonpryor
Something went wrong with that request. Please try again.