* Use the existing information we have in the Frameworks class to determine
whether a particular framework works in the simulator or not.
* Show a warning (MX5223) when we run into such a framework, but only if
the linker is enabled (otherwise we'll often get warnings for API the developer
doesn't use).
* [xcode12] Initial bump for Xcode 12 GM
* [tests][intro] We cannot load CoreNFC framework on iOS simulator anymore
* [tests][xtro] New Metal API are not abstract (before XAMCORE_4_0)
* [tests][intro] Fix crash when CSLocalizedString 'description' selector is called
* [tests][xtro] Add support for excluding platforms
Based on `Make.config` variables `INCLUDE_[IOS|TVOS|WATCH|MAC]`
This required moving some entries (common -> macOS) to keep the
sanitizer happy.
* [xtro] Ignore Intents watchOS differences since they will likely match iOS in the future
* Update to use Xcode 12 GMb instead of the old GM
* [tests][xtro] Remove OSLog for iOS and tvOS (changed in GM)
* [tests][msbuild] Disable FrameworkListTest based on the active/disabled platforms
* [tests][msbuild] Track new directory/file inside CoreML projects
* [mlaunch] Bump maccore and disable mlaunch if mac build is disabled
New commits in xamarin/maccore:
* xamarin/maccore@ba332d4d07 Disable mlaunch if Mac is not built (#2314)
Diff: 87a96d21c9..ba332d4d07
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Most fixes are inside Intents. Some types were not available on macOS
and marked as such, except it backfired.
* Adding `[NoMac]` on `XAMCORE_4_0` was fine
* Adding `[Obsolete]` outside `XAMCORE_4_0` was fine
* Removing the `[Mac (x,y)]` was not quite fine. It's true (since it was never on macOS) but removing it means it default to the oldest (10.9) macOS version we support. This is what the introspection tests were expecting.
Adding an `[Obsoleted (..., 10,0, ...)]` solve this.
* Fix links that point to master to point to main instead.
* Implement support in the sample tester for specifying the default branch for
each sample repo.
* Fix various text / documentation to say 'main' instead of 'master.'
* Push to 'main' instead of 'master' in xamarin-macios-data.
* Fix xharness to make 'main' the special branch with regards to documentation tests as opposed to 'master'.
* Fix various CI to use 'main' instead of 'master'.
This is a backport of PR #9561
Calling Uri.PathAndQuery is not allowed on a relative Uri, which made the
previous Uri -> NSUrl implicit operator always throw if given a relative
NSUrl.
So I fixed that, added several tests, and found another issue (it turns out
that 'url.RelativePath == url.Path' is not a reliable way to detect absolute
urls, because it's true for relative urls as well) and fixed that too.
Fixes https://github.com/xamarin/xamarin-macios/issues/9607.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [fileprovider] Update for Xcode 12 beta 6
This was quite noisy. Apple removed all API marked as
`FILEPROVIDER_API_AVAILABILITY_V3`.
```
```
Most were bound but they were (majority) decorated with `[NoiOS]` and
`[NoMac]` so they did not generated any bindings.
A few of them were modified or just became macOS-only.
Deprecation warnings also needed to be updated.
Checked and the other functions that are similar to the new ones are not
bound. We only do this framework partially, so I'm adding them to the
ignore until we have a customer that requires them.
Although the headers are present, the framework cannot be used since the
header references AVAudioSession and is a class that is not present in
MacOS X
* [Submission] Fix all the selectors that apple warns about. (#9268)
We have noticed the following message from Apple when performing
submissions with Xamarin.iOS:
> ITMS-90338: Non-public API usage - The app references non-public
> selectors in WcBc.iOS: behaviorTypes, convolutionState,
> discoverAllContactUserInfosWithCompletionHandler:,
> discoverAllContactsCompletionBlock,
> discoverUserInfoWithEmailAddress:completionHandler:,
> discoverUserInfoWithUserRecordID:completionHandler:,
> discoverUserInfosCompletionBlock, displayContact, drawableResizesAsynchronously,
> encodeToCommandBuffer:sourceImage:convolutionState:,
> encodeToCommandBuffer:sourceImage:destinationImage:state:,
> getProperty:onChannel:responseHandler:, hasProperty:onChannel:responseHandler:,
> initWithEmailAddresses:userRecordIDs:, initWithMIDIEntity:dataReadyHandler:,
> initWithZoneID:options:, initWithZoneID:subscriptionID:options:,
> isPublicDatabase, mouseUpAction, newDrawable, propertyChangedCallback,
> removeAllAppearanceStreams, replaceTextStorage:, retrieveConnectedPeripherals,
> retrievePeripherals:, setDiscoverAllContactsCompletionBlock:,
> setDiscoverUserInfosCompletionBlock:, setDrawableResizesAsynchronously:,
> setEditedMask:, setMouseUpAction:, setMovieControlMode:,
> setProperty:onChannel:responseHandler:, setPropertyChangedCallback:,
> setSocketFamily:, setTemporaryAttributes:forCharacterRange:, setUserRecordIDs:,
> sourceOffset, subscriptionOptions, takeBackgroundColorFrom:, takePasswordFrom:,
> temporalAntialiasingEnabled, userRecordIDs. If method names in your source code
> match the private Apple APIs listed above, altering your method names will help
> prevent this app from being flagged in future submissions. In addition, note
> that one or more of the above APIs may be located in a static library that was
> included with your app. If so, they must be removed. For further information,
> visit the Technical Support Information at http://developer.apple.com/support/technical/
All of them have been removed but without a break in the API excep
"initWithMIDIEntity:dataReadyHandler:" wich does look like an error on
Apples side.
Empty stubs are used as much as possible except on those cases in which
a handler is called or an output variable should be modified (buffer,
out param) to minimize the users surprise at runtime.