Switch branches/tags
Nothing to show
Commits on May 2, 2014
  1. Don't build Mono.Android.GoogleMaps.dll for API-13.

    We don't build/ship API-13 for any other assemblies, so this just
    wastes build time for something that'll never be used.
    jonpryor committed May 2, 2014
Commits on Apr 29, 2014
  1. Really fix the previous change.

    vargaz committed Apr 29, 2014
  2. Fix the previous change.

    vargaz committed Apr 29, 2014
  3. Get rid of get-maps.jar-path and do its work in the shell code where …

    …it was previously invoked.
    vargaz committed Apr 29, 2014
Commits on Apr 28, 2014
  1. Merge pull request #3 from mono/fix-maps-build

    Fix finding the maps.jar archive
    grendello committed Apr 28, 2014
  2. Fix finding the maps.jar archive

    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.
    grendello committed Apr 28, 2014
Commits on Apr 14, 2014
Commits on Apr 8, 2014

    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.
    jonpryor committed Apr 8, 2014
Commits on Apr 2, 2014
  1. Fix path capture in `find` for google maps component.

    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.
    atsushieno committed Apr 2, 2014
Commits on Feb 20, 2014
  1. Specify the latest android platform to eliminate extraneous build war…

    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(
    atsushieno committed Feb 20, 2014
Commits on Jan 9, 2014
Commits on Nov 1, 2013
  1. Remove not-supported API so far (non-instantiated generic type derive…

    …d from generic type and exposes collection).
    atsushieno committed Nov 1, 2013
Commits on Jul 30, 2013
  1. Fix member compatibility in DrawerLayout, SlidingPaneLayout.

    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.
    jonpryor committed Jul 30, 2013
Commits on Jul 24, 2013
  1. Ignore They don't exist in the publ…

    …ic API yet break build.
    atsushieno committed Jul 24, 2013
Commits on Jun 27, 2013
  1. Give parameter names to support library bindings.

    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.
    atsushieno committed Jun 27, 2013
Commits on Nov 30, 2012
  1. Revert "compatibility-v13 cannot be built for arbitrary API level."

    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.
    jonpryor committed Nov 30, 2012
Commits on Nov 8, 2012
  1. hush mdoc.

    atsushieno committed Nov 8, 2012
Commits on Nov 2, 2012
  1. [GoogleMaps] Fix enum types.

    OverlayItem.GetMarker(ItemState) and MapActivity.OnGetMapDataSource()
    weren't bound because they used enum types that didn't exist. (Oops.)
    Reported by: Goncalo Oliveira
    jonpryor committed Nov 2, 2012
Commits on Aug 31, 2012
Commits on Jul 12, 2012
  1. [GoogleMaps] Rework maps.jar resolution.

    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.
    jonpryor committed Jul 12, 2012
Commits on Jun 5, 2012
Commits on Apr 17, 2012
Commits on Apr 16, 2012
  1. Fix maps.jar path

    shana committed Apr 16, 2012
Commits on Apr 13, 2012
  1. [GoogleMaps] Support ANDROID_SDK_PATH being a symlink.

    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).
    jonpryor committed Apr 13, 2012
  2. [Mono.Android.GoogleMaps] Generate merged API assemblies.

    (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 ...
    jonpryor committed Apr 12, 2012
  3. Revert support for "any" API level

    Revert commit 0419ac5; we're doing "any" support differently.
    jonpryor committed Apr 11, 2012
Commits on Apr 10, 2012
Commits on Apr 4, 2012
  1. [GoogleMaps] Add support for "any" API level.

    The "any" API level needs to be mapped to the $(API_ANY_LEVEL) level,
    as it's not a Google-defined Android API level.
    jonpryor committed Apr 4, 2012
Commits on Mar 15, 2012
Commits on Mar 5, 2012
Commits on Mar 2, 2012