Tests were failing because the manager was getting dispose and the
delegate was not. We ran into the failure because there was a device
close to the lab with the UUID that was being used.
The change uses a even more common UUID (heart monitor), which should
increase the chances to pick up a device and re-orgs the disposal of the
manager and the delegate.
This was confirmed with a BLE device, watchOS does not like us to try
and access it as a bluetooth device and is 'hacky'.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7108
Tweak the watchOS architecture test to build for bitcode when building with
llvm, since that's what's usually done.
Also tweak the MT0145 error message a bit.
Fixes https://github.com/xamarin/maccore/issues/1994.
Types that are new in 64bits only OS are generated differently on 32bits
bindings. They mainly throw a `PlatformNotSupportedException` so it's
easier to diagnose (than a crash) what's happening at runtime.
This works well in all cases except one. When a new type, let's say
`UIMenuElement` is added **and** serves as a new base type for existing
types.
`UIKeyCommand` (iOS 7) -> `UICommand` (iOS 13)-> `UIMenuElement` (iOS 13)
This is _correct_ as new base types can be added (in ObjC and C#).
However the generated code for the constructors of `UICommand` and
`UIMenuElement` would be throwing a `PlatformNotSupportedException`
which breaks the `UIKeyCommand` on 32 bits devices.
We fixed this in a few places by tweaking the availability attribute
but that requires spotting the new base type while doing bindings and
that is error prone [1][2].
This PR simply does let the `protected` constructor, using when chaining,
be generated normally. It's simpler and will cover all the cases (without
requiring hacks in the availability of those types)
[1] https://github.com/xamarin/xamarin-macios/issues/7083
[2] https://github.com/xamarin/xamarin-macios/issues/7084
Types that are new in 64bits only OS are generated differently on 32bits
bindings. They mainly throw a `PlatformNotSupportedException` so it's
easier to diagnose (than a crash) what's happening at runtime.
This works well in all cases except one. When a new type, let's say
`UIMenuElement` is added **and** serves as a new base type for existing
types.
`UIKeyCommand` (iOS 7) -> `UICommand` (iOS 13)-> `UIMenuElement` (iOS 13)
This is _correct_ as new base types can be added (in ObjC and C#).
However the generated code for the constructors of `UICommand` and
`UIMenuElement` would be throwing a `PlatformNotSupportedException`
which breaks the `UIKeyCommand` on 32 bits devices.
We fixed this in a few places by tweaking the availability attribute
but that requires spotting the new base type while doing bindings and
that is error prone [1][2].
This PR simply does let the `protected` constructor, using when chaining,
be generated normally. It's simpler and will cover all the cases (without
requiring hacks in the availability of those types)
[1] https://github.com/xamarin/xamarin-macios/issues/7083
[2] https://github.com/xamarin/xamarin-macios/issues/7084
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@70d6903053 [2019-08] [merp] Use a separate program as the hang supervisor. (#16900)
* mono/mono@4bff2b6370 [offsets-tool] Install clang into the user-specific python directory.
* mono/mono@81894ec8ca Implement WriteCore and ReadCore in DeflateStream
* mono/mono@bfbf823ca1 [ci] Remove more XCODE32_DIR usages (#16964)
* mono/mono@ce01b20a4d Add net_4.8.xml to EXTRA_DIST and bump binary-reference-assemblies again
* mono/mono@7a587d7fa6 Add .NET 4.8 reference assemblies (#16912)
* mono/mono@35e454a8f6 [sdks] Remove the mac32 build. (#16936)
* mono/mono@75eb342f53 [2019-08] [System] Make FileSystemWatcher backend non-static (#16926)
* mono/mono@5881981f79 [2019-08] [mini] Add missing membars when initializing rgctx entries (#16909)
* mono/mono@6290b6cd6e Temporarily disable embedded ppdb data decompression (#16911)
* mono/mono@a0e7f9eaf2 [2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter (#16886)
* mono/mono@6275840a7f Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16901)
* mono/mono@25f6093283 [corlib] Fix building nunit-lite twice (#16895)
* mono/mono@7ec17ba1be [2019-08] [android sdk] Add aprofutil tool (#16884)
* mono/mono@f755f3b539 [metadata] Fix leaks when handling a few attributes (#16850)
* mono/mono@5f9a2db39b [2019-08] Fix infrequent hangs in test-runner. (#16854)
* mono/mono@f31f5ea1f1 [2019-08] [threads] do not convert NULL thread name (#16828)
* mono/mono@20308e6f87 [aot] Do not wrap tool_prefix path when calling strip (#16820)
* mono/mono@cecda47c48 [aprofutil] Add -p and -f options
* mono/mono@824cc12ac3 Bump to mono/corefx@e79cf5b
* mono/mono@b77dc06a7e [aprofutil] Install the tool correctly (#16112)
* mono/mono@1848d78d60 [aotprof-tool] Initial import of AOT profiler tool (#15384)
* mono/mono@da0086e304 [2019-08] Add RenamedEvent* to FSW sources from CoreFX (#16756)
* mono/mono@0297b21b03 [msbuild][roslyn] Bump msbuild and roslyn to pull in new versions (#16768)
* mono/mono@40631e3b9e [2019-08] [aot] move method_addresses to data.rel.so section to avoid text relocations (#16751)
* mono/mono@68b77674e2 Vtable [i] can be null so this should be check before use it. Fixes#16712
* mono/mono@4a0b4f41ed [mini] publish global patches after JitInfo has been added
* mono/mono@7a1f63fde6 [debugger][android] It was not initialising seq_points on MonoCompile on Android, so when was compiling dynamic methods, seq_points wasn't created and we got the assert when try to single step.
Diff: 29b1ac19c9..70d6903053
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* One more test fix.
In iOS 13 it's no longer possible to get PACs from file:// urls (this is
explained in the release notes, so it's expected). So launch a local
httpserver and serve the PAC that way.
link-framework-1 ensures that we link away as many frameworks as possible.
Unfortunately there are things we can't link away when using the dynamic
registrar, so switch to testing the Release configuration instead, since that
automatically uses the static registrar (and the release configuration is the
better option to test anyway, since it's closer to what customers use to
release).
In iOS 13 it's no longer possible to get PACs from file:// urls (this is
explained in the release notes, so it's expected). So launch a local
httpserver and serve the PAC that way.
link-framework-1 ensures that we link away as many frameworks as possible.
Unfortunately there are things we can't link away when using the dynamic
registrar, so switch to testing the Release configuration instead, since that
automatically uses the static registrar (and the release configuration is the
better option to test anyway, since it's closer to what customers use to
release).
This should let us provide a nicer API for the GM change about
`CBManager authorization` moving from an instance to a static
property (in all but iOS 13.0 / watchOS 6.0)
For some reason (likely to be added back later ?) Xcode 11 GM removed
most of new macOS 10.15 API for FileProvider.
So instead of deleting stuff this uses a lot of `[NoMac]` even if some
API are actually not part of any platform anymore, e.g. you can see the
following line in the GM headers
```
API_UNAVAILABLE(watchos, tvos) API_UNAVAILABLE(ios, macos)
```
We ship a default, pre-built, simlauncher for iOS simulator applications.
This speeds up compilation for the default (non linked) simulator builds
quite a lot (no call to `clang` is needed). However it force us to keep
track of frameworks manually - `mtouch` can track them but requires
calling clang/ld to finish things up (killing the optimization).
It's easy to forget some (new) frameworks since they can be loaded
dynamically (on demand) _most_ of the time. Sadly there are a few cases
where doing so cause (hard to diagnose) problems - so we can't depend
on them being loaded, correctly for us.
The new test case loads the `otool -L` output (make when we build
simlauncher[32|64]-sgen) and compares it with mtouch's GetFramework
logic *and* with our namespaces (which is pretty close, with a few
exceptions, to the framework names). This will make it harder to
forget [weak] frameworks when adding new bindings :)
Fixes https://github.com/xamarin/xamarin-macios/issues/6951
* [registrar] Report a warning when the registrar export an abstract INativeObject type to Objective-C.
Exporting abstract types to Objective-C can lead to problems when at runtime
we're asked to create an instance of such a type (which we can't), so warn
when this happens.
This would have caught #6655, and the problems explained in #4969 as well.
Since this may trigger for code that's currently working fine, I'm making it a
warning instead of an error (which means adding some extra code to be able to
easily report warnings from the generator code).
* Don't assume a TypeReference can be successfully resolved every time.
Included changes are:
* New Cecil API in 2019-08
* Permit new symbols from networkable AOT profiler in symbols test
* Bump Mono to include fix for zlib linking, and new Cecil API
* We need to link against zlib now, if using libmono.a
* [Tests] Ignore memory hungry tests in old devices. (#6913)
* Ignore certain tests that use too many resources in old devices.
* Add missing tests that use too much memory on 32b devices.
* Add a dummy x86_64 slice to all our native libraries that don't have one. (#6848)
Apple's notarization tool has a bug where they incorrectly flag Mach-O
binaries without an x86_64 slice, so make sure all our libraries have one.
* Jenkinsfile notarization (#6869)
* Add in notarization script for xamarin.mac/xamarin.iOS
* Flatten the list to get rid of the braces
* Add in keychain password
* Add login.keychain back in to access codesigning certificates
* Always sign pkgs, upload notarized copies
* Enable ios notarization and make notarized pkgs public
* Make notarization non-fatal
* Publish GH statuses for notarized PKGs
* Don't forget to declare URI variables for notarized pkgs
* report proper package links
* [jenkins] Improve package reporting.
* Use dummy function name which our tests won't complain about.
Only check that setting `tintColor` to `nil` gives us back some
default color - IOW we only care it's not-null, the exact color
has no value being tested.
CoreAudioTypes is _new_ but it's just some stuff that moved around,
however it now shows up separately in our API diff (and was quite
large because of the removal/addition caused by moving headers)
* Add a dummy x86_64 slice to all our native libraries that don't have one. (#6848)
Apple's notarization tool has a bug where they incorrectly flag Mach-O
binaries without an x86_64 slice, so make sure all our libraries have one.
* Jenkinsfile notarization (#6869)
* Add in notarization script for xamarin.mac/xamarin.iOS
* Flatten the list to get rid of the braces
* Add in keychain password
* Add login.keychain back in to access codesigning certificates
* Always sign pkgs, upload notarized copies
* Enable ios notarization and make notarized pkgs public
* Make notarization non-fatal
* Publish GH statuses for notarized PKGs
* Don't forget to declare URI variables for notarized pkgs
* report proper package links
* [jenkins] Improve package reporting.
* Use dummy function name which our tests won't complain about.
* [foundation] Expose AllowsCellularAccess on NSUrlSessionHandler (#6059)
This property was always set to `true` but it can be useful to turn it
off (and that was not easy with the existing implementation)
* [Foundation] Ensure that we allow celullar data by default until the user says otherwise. #6762
The default value in the NSUrlSession is to allow cellular data. This
small change closes the issue, since users will not have an unexpected
result.
Later we need to provide a proper fix to allow the property to be
exposed AND used the value of the session.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6762
* [Foundation] Ensure that we allow celullar data by default until the user says otherwise. #6762
The default value in the NSUrlSession is to allow cellular data. This
small change closes the issue, since users will not have an unexpected
result.
Later we need to provide a proper fix to allow the property to be
exposed AND used the value of the session.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6762
* [monotouch-test] Apple has fixed a crash in the ImageCaptioningTest, so update the test accordingly.
Apple has fixed a crash we ran into with the ImageCaptioningTest, so now we
can re-enable the code that caused the crash.
* Fix test in the simulator.
* Fix test build failure for Xamarin.Mac.
Make CNFetchResult generic (which it is in Objective-C), and add a generic
version of NSEnumerator (which Objective-C also has), so that we can bind two
API in CNContactStore that uses generic versions of those types.
Fixes https://github.com/xamarin/xamarin-macios/issues/6561.
Calls to CTFontManagerRegisterFontDescriptors with a null callback will crash
unless on iOS 13.1, so don't run this test on earlier OS versions.
Also update AssertXcodeVersion to cope with Xcode 11.1, which is unfortunately
just guesswork until an actual Xcode 11.1 is released (currently we can't
distinguish between iOS 13.0 and iOS 13.1 using the Xcode version, because
Xcode 11b7 supports them both, so for now we assume there will be an Xcode
11.1 which will support iOS 13.1).
Support for `NSValue`/`CGAffineTransform` exists in iOS/tvOS/watchOS,
from UIKit, but not for macOS. However this will be required for the
new protocols inside CoreImage.
Also add an overload for `StoreValueAtAddress` since the original
one was deprecated but we did not provide the new alternative to
update the code.
Xcode 11 doesn't support anything below iOS 7.0 (the linker will automatically
change the deployment target to 7.0), so we need to drop support as well
(since our native bits will be targetting iOS 7.0, and we can't change that).
https://github.com/xamarin/xamarin-macios/issues/6213
* Build native code with -std=c++14.
Apple's headers now require -std=c++14 to compile their headers in C++ mode.
This fixes a compile error that would occur with the PhotosUI framework when
compiling code for C++.
* [mmp] Use -std=c++14 when compiling.
* Fix command line output.
* [mmp] Add all source files at the end, so they all get the -x clang argument applied.
* Limit when using c++14 in mtouch according to language.
Also limit the output from the native compiler, so that we don't overload the
IDEs with output if the native compiler produces tens of thousands of errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/6526.
* [registrar] Fix verification of generic parameters to accept unrelated generic types. Fixes#6687.
When we export generic classes to Objective-C, we verify that any generic
parameters are constrained so that we know how to handle them.
Example:
class MyObj<T> : NSObject where T: NSObject
{
[Export ("foo:")]
public void Foo (T obj);
}
in this case we verify that the parameter T is constrained to NSObject, so
that we can treat the argument like an NSObject.
The problem was when the function contained a generic type which was not
related to T:
class MyObj<T> : NSObject where T: NSObject
{
[Export ("foo:")]
public void Foo (Action<int> obj);
}
in which case the same logic would kick in and reject the Action<int> type
since it's not related to NSObject (no generic arguments could be found, and
the default response was 'not valid').
So I've changed the default response for generic types that are unrelated to
the generic parameter we're verifying to accept such types.
Fixes https://github.com/xamarin/xamarin-macios/issues/6687.
* No need to use a UIViewController as the super class, NSObject works just fine for this test.
Fixes the test build on macOS.
Xcode 10.3 was released over the summer with a very small subset
of the (already out) Xcode 11 betas API.
This PR fix some availability attributes and also ensure we can
run introspection tests successfully on an iOS 12.4 device.
This test started failing on iOS 13 beta 5. It is still failing on beta 7.
This test is designed to fail at every new iOS version until it's fixed by Apple.
Let's ignore it for good, mention it in https://github.com/xamarin/xamarin-macios/issues/6212 and check it one last time at GM.
FYI iOS 13 changed the tint color for the red pin, it's now (255, 69, 58, 255) instead of (255, 59, 48, 255).
Let's not test iOS colors for Apple (:
A simple NotNull check should be enough.
We were getting:
```
Xamarin.MTouch.LinkerWarnings: The warning 'MT5203: Native linking warning: warning: ignoring file /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/test-libraries/.libs/ios/libtest.x86_64.a, building for iOS Simulator-i386 but attempting to link with file built for unknown-archive' was not found in the output:
Message #1 did not match:
actual: 'Native linking warning: warning: ignoring file /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/test-libraries/.libs/ios/libtest.x86_64.a, building for iOS Simulator-i386 but attempting to link with file built for iOS Simulator-x86_64'
expected: 'Native linking warning: warning: ignoring file /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/test-libraries/.libs/ios/libtest.x86_64.a, building for iOS Simulator-i386 but attempting to link with file built for unknown-archive'
```
New framework - but it includes some of iOS API that were previously in
QuickLook.framework. Types were moved but remains in the old namespace
until `XAMCORE_4_0` is defined.
The `enum` is decorated with `[Obsolete]` since it's unused by any API.
However recent logic skips obsolete members it so it looks missing...
even if it won't be removed until `XAMCORE_4_0` is enabled.
Not quite clear why the original PR [1] did not report it... but all
subsequent ones are
https://github.com/xamarin/xamarin-macios/pull/6767
`gamePlayerID` and `teamPlayerID` are decorated as `[iOS (12,4)]...` since
the headers mention so in both Xcode 11 betas and the recent 10.3 (stable)
https://github.com/xamarin/xamarin-macios/wiki/GameKit-iOS-xcode103-final
The `enum GKError` has been unified (at some point) so it was simplified.
* [WatchKit] Remove this framework for iOS while keeping backwards compatibility. Fixes#6492.
* Copy all generated sources and modify them to throw PlatformNotSupported exceptions.
* Adjust some existing source code to also throw PlatformNotSupported exceptions.
* Sprinkle Obsolete attributes generously.
* Stop generating code for the WatchKit framework for iOS.
Fixes https://github.com/xamarin/xamarin-macios/issues/6492.
* [introspection] Adjust test.
* [mtouch] Don't link with WatchKit, and show a warning if we detect code that want to use WatchKit.
* [xtro] Remove WatchKit for iOS.
* [introspection] Don't check obsoleted NSString fields for null.
There's probably a reason the field was obsoleted.
* [introspection] Add exception for the WatchKit framework.
* [xtro] Ignore obsolete enums.
There's probably a reason they're obsoleted.
In particular it solves a confusion between WKWebKit.WKErrorCode and
WatchKit.WKErrorCode: for iOS, the latter is obsoleted, and this way we always
process the former instead.
* [mtouch] Adjust wording for MT4178 to be more accurate.
* [WatchKit] Make more API obsolete/hidden.
Two classes managed to slip past the first time.
* [tests] Adjust test after WatchKit removal.
Also introduce `PlatformName.MacCatalyst` while keeping the old
`UIKitForMac`, with the same value, until we can clean up existing
bindings globally (and without too much conflicts).
Moved some code from uikit.cs since the type moved a while ago. That
ease code sharing with macOS (XM) but it stays into the UIKit namespace
(for XI) until `XAMCORE_4_0` to ensure binary compatibility.
* [linker] Always preserve INativeObject (interface) on types. Fixes#6711
Recent versions of the linker can remove _unused_ interfaces from types.
This optimization is only done when the type is not instantiated. However
our tools and runtime requires knowing if a type represent a native
object, using `INativeObject` even if the code that creates such instance
is not marked.
In details... the issue happens because the static registrar must be able
to detect that `MTAudioProcessingTap` is a native object, so it checks
if it implements `INativeObject`. Since it does not it fails with a 4104
error.
Why does it not ? because it's handled specially by the generator and
uses `FromHandle` to lookup (not create) instance. So the linker is able
to remove the creation code (totally fine) and then remove the
`INativeObject` (not fine since we need this).
The solution is to tell (a small like to) the linker that any marked type
that implements `INativeObject` is instantiated. That way we ensure that
the tooling (run against the linked app) and the runtime can determine
those types as native.
reference: https://github.com/xamarin/xamarin-macios/issues/6711
* Move code (to a better location) to avoid collection/exception changes. Also add an unit test
* Exclude new test case from watchOS since it does not ship with MediaToolbox
No change in beta 2 to 5
* Run EmbeddingTest.Vector test on iOS and macOS only
reference: rdar 44948030
> Engineering has the following feedback for you: The tagging
> depends on the NLP assets being present on the device. The
> assets get downloaded through OTA. OTA download for NLP assets
> does not exist on watchOS and tvOS currently…only on iOS and
> macOS. It is conceivable that the assets got downloaded when you
> were on WiFi at a later point. So, the tagging should work.
See https://github.com/xamarin/maccore/issues/1808.
On `xcode11` we do not support mono binaries.
VSTS expects to be able to download mono when we need to build it from source for `xcode11`.
Reverting the tests to the old way would be too complicated to simply disable the bcl tests.
Those tests are still executed for simulator and will be re-enabled when we merge `xcode11`.
This was added as a reminder here: https://github.com/xamarin/xamarin-macios/issues/6212
Recent versions of the linker can remove _unused_ interfaces from types.
This optimization is only done when the type is not instantiated. However
our tools and runtime requires knowing if a type represent a native
object, using `INativeObject` even if the code that creates such instance
is not marked.
In details... the issue happens because the static registrar must be able
to detect that `MTAudioProcessingTap` is a native object, so it checks
if it implements `INativeObject`. Since it does not it fails with a 4104
error.
Why does it not ? because it's handled specially by the generator and
uses `FromHandle` to lookup (not create) instance. So the linker is able
to remove the creation code (totally fine) and then remove the
`INativeObject` (not fine since we need this).
The solution is to tell (a small like to) the linker that any marked type
that implements `INativeObject` is instantiated. That way we ensure that
the tooling (run against the linked app) and the runtime can determine
those types as native.
reference: https://github.com/xamarin/xamarin-macios/issues/6711
The dispose of `nslang` was happening outside of the check if `nslang` is null. This was causing a crash when trying to recognise a string that contains just one number.
The dispose of `nslang` was happening outside of the check if `nslang` is null. This was causing a crash when trying to recognise a string that contains just one number.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6688
Rolf Bjarne Kvinge
Difegue
Manuel de la Pena
Alex Soto
Vincent Dondain
monojenkins
Sebastien Pouliot
Bernhard Urban
Waleed Chaudhry
Whitney Schmidt
Jo Shields
Jonathan CONTE
Jonathan CONTE
Juxhin (Eugene) Bakalli