* 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.
Issue was reponed because users had a valid reason to want to bypass
this security check. The HttpClient should be able to work in a
background task. So we now provide a way for users to explicitly ignore
the check.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6443
* [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
Ensure that we do lock when we are trying to remove the notification obj from the notification center so that another thread does not try to remove a null obj.
* [Foundation] Ensure that the collection is not modified during the loop. #6704
Collections should not be modified during the loop, this is bad
practice and was a side effect of the TrySetCanceled. Is better to
create a temp collection with all the sources and cancel each of them.
Fixes https://github.com/xamarin/xamarin-macios/issues/6704
When building mtouch locally, this will be the mtouch path:
/path/to/somewhere/xamarin-macios/_ios-build//Library/Frameworks/Xamarin.iOS.framework/Versions/git/bin/mtouch
brew may fail to install 7z if 7z is already installed, so ignore any brew
failures when trying to install 7z.
If 7z really is non-functional on the machine, then it'll fail later anyway.
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.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6688
In some cases some bots will return a proxy present, not because of the
PAC being parsed, but due to the bot settings. Ignore the tests that
expect no proxies in the CI fixes the issue.
Fixes https://github.com/xamarin/maccore/issues/1901
A change in the linker made a potential problem show up as a registrar error
instead of a runtime exception.
The linker became smarter in d16-2, and will now remove interface
implementations in certain cases. In particular, the linker will remove
interface implementations for a type that is never instantiated (which means
there will never be any instances of that type, which means the interface
won't be needed).
The ABRecord was abstract, and as such there will never be any ABRecord
instances. If none of ABRecord's subclasses are used in the app, there won't
be instances of ABRecord subclasses either.
This meant the linker removed all of ABRecord's interfaces, including
INativeObject.
We have API that uses ABRecord in the signature. The registrar needs to know
if a particular type is an INativeObject, which is determined by checking if
the type implements the INativeObject interface. Since the INativeObject
interface implementation was removed, the registrar determined that the
ABRecord type in the signature is invalid, and showed an error:
Error MT4136: The registrar cannot marshal the parameter type 'AddressBook.ABRecord' of the parameter 'address' in the method 'PassKit.PKPaymentAuthorizationViewController/_PKPaymentAuthorizationViewControllerDelegate.DidSelectShippingAddress(PassKit.PKPaymentAuthorizationViewController,AddressBook.ABRecord,PassKit.PKPaymentShippingAddressSelected)
The actual problem is not the linker change, but the fact that a signature
uses an abstract type. At runtime, this will cause problems if we ever need to
instantiate such a managed type: we can't. This is generally not a problem for
NSObject subclasses, because we can determine the runtime type of the object,
and that's usually [1] some other, non-abstract type. However, for
INativeObjects, we can't find a better type at runtime (because we can't
determine the runtime type of the object), so we're left with trying to
instantiate the exact type in the signature. If this is an abstract type,
things will go badly.
So make ABRecord non-abstract.
Fixes https://github.com/xamarin/xamarin-macios/issues/6654.
[1] Usually, but not always, as history has shown. See also https://github.com/xamarin/xamarin-macios/issues/4969.