Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Commits on May 2, 2014
  1. Jonathan Pryor

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

    jonpryor authored
    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. Zoltan Varga

    Really fix the previous change.

    vargaz authored
  2. Zoltan Varga

    Fix the previous change.

    vargaz authored
  3. Zoltan Varga
  4. Zoltan Varga
  5. Zoltan Varga

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

    vargaz authored
    …it was previously invoked.
Commits on Apr 28, 2014
  1. Marek Habersack

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

    grendello authored
    Fix finding the maps.jar archive
  2. Marek Habersack

    Fix finding the maps.jar archive

    grendello authored
    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.
Commits on Apr 14, 2014
  1. Atsushi Eno
  2. Atsushi Eno
Commits on Apr 8, 2014
  1. Jonathan Pryor

    Obsolete ALL THE ASSEMBLIES!

    jonpryor authored
    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 [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:
    
    	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.
    
    [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. Atsushi Eno

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

    atsushieno authored
    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. Atsushi Eno

    Specify the latest android platform to eliminate extraneous build war…

    atsushieno authored
    …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)
Commits on Jan 9, 2014
  1. Atsushi Eno
Commits on Nov 1, 2013
  1. Atsushi Eno

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

    atsushieno authored
    …d from generic type and exposes collection).
Commits on Jul 30, 2013
  1. Jonathan Pryor

    Fix member compatibility in DrawerLayout, SlidingPaneLayout.

    jonpryor authored
    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. Atsushi Eno
Commits on Jun 27, 2013
  1. Atsushi Eno

    Give parameter names to support library bindings.

    atsushieno authored
    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. Jonathan Pryor

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

    jonpryor authored
    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. Atsushi Eno

    hush mdoc.

    atsushieno authored
Commits on Nov 2, 2012
  1. Jonathan Pryor

    [GoogleMaps] Fix enum types.

    jonpryor authored
    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
Commits on Aug 31, 2012
  1. Atsushi Eno
Commits on Jul 12, 2012
  1. Jonathan Pryor

    [GoogleMaps] Rework maps.jar resolution.

    jonpryor authored
    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.
Commits on Jun 5, 2012
  1. Atsushi Eno
Commits on Apr 17, 2012
  1. Jonathan Pobst
Commits on Apr 16, 2012
  1. Andreia Gaita
  2. Andreia Gaita

    Fix maps.jar path

    shana authored
Commits on Apr 13, 2012
  1. Jonathan Pryor

    [GoogleMaps] Support ANDROID_SDK_PATH being a symlink.

    jonpryor authored
    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. Jonathan Pryor

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

    jonpryor authored
    (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 ...
  3. Jonathan Pryor

    Revert support for "any" API level

    jonpryor authored
    Revert commit 0419ac5; we're doing "any" support differently.
Commits on Apr 10, 2012
  1. Andreia Gaita
Commits on Apr 4, 2012
  1. Jonathan Pryor

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

    jonpryor authored
    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. Jonathan Pobst
Commits on Mar 5, 2012
  1. Atsushi Eno
Commits on Mar 2, 2012
  1. Jonathan Pryor
Something went wrong with that request. Please try again.