DPC migration is available from Android P, i.e. a device can be re-enrolled to a new EMM without factory reset it.
My question is: does the Android Device Policy support this feature? If so, does it support it in both ways, i.e. migrating from or to the Android Management API?
The Android Management API doesn't support DPC migration at the moment.
We don't have any timeline to share about when it will be supported as we are still evaluating the use cases and requirements.
One use case is to allow migrating from custom DPC to the Android Management API, but the feedback we received so far is that it's simpler to support both DPCs for a while as devices are refreshed.
Related
Im trying to add some analytics and crash logging to our app, so am implementing the app center since it seems like the perfect fit. We're running xamarin forms targeting iOS/Android/UWP.
I'm trying to add some exception handling in our shared project to throw the exception information up to the appCenter. When i add the following to one of our exceptions:
Crashes.TrackError(ex);
I get a warning saying:
'Crashes.TrackError(Exception, IDictionary<string, string>)' is obsolete: 'This does not exist in UWP and should not be used.'
What should we be using in it's place to pass out the exception to the appcenter for all platforms?
Microsoft AppCenter does not currently support the same API feature set on UWP vs Xamarin so TrackError is not available (March+ timeframe) ((As Guillaume Perrot answer stated and linked GitHub issue highlights).
Important
UWP only supports starting Crashes with AppCenter.Start and none of the other API calls provided by the Crashes class are supported on UWP, They only work for Xamarin.iOS, Xamarin.Android and Xamarin.Forms apps deployed to iOS and Android.
re: https://learn.microsoft.com/en-us/appcenter/sdk/crashes/uwp
You could use App Center's Analytics as a stop-gap and define a custom Event (HandledException) and use the TrackEvent name/event properties to track your handled exceptions (it only supports 125 chars per name/event, but better then nothing).
those APIs are not yet supported (as of 2/13/2019) on windows platforms. They are visible as portable library needs to support them but are only implemented on Android and iOS platforms.
You can be notified on progress on this feature at https://github.com/Microsoft/AppCenter-SDK-DotNet/issues/669.
Recently i got a project which was build on Xamarin on Mac.Now, when i try to open this project on visual studio for MAC (As you all know Xamarin is now visual studio for MAC) it shows some errors regarding Monotouch.
The question is : Do i really need to convert app to unified API ? i know there is tutorial on official Xamarin doc to change app to unified API, but if there is any other way to open app without migrating to unified api.And what will be advantages and disadvantages of migration?
There are quite a few reasons why you might consider updating, but I will highlight some of the more important ones. Firstly consider that Apple as a manufacturer of hardware and software have always striven to keep their devices upto date, as such lagging behind as an iOS app developer can absolutely effect the demand for your app.
Firstly it already became a push or jump situation, as Xamarin stopped updating or supporting feature additions to their 'classic api' (As of writing we are on iOS 10.3).
The complete removal of classic support is scheduled for next fall
with the release of Xamarin.iOS 10.0.
Secondly the unified API is required to meet apples desire to support 64bit architecture:
The new Unified APIs are required to support 64 bit device
architectures from a Xamarin.iOS mobile application. As of February
1st, 2015 Apple requires that all new app submissions to the iTunes
App Store support 64 bit architectures.
As to your concern regarding the dissadvantages, I will simply say that the migration can either go smoothly, or not so smoothly. It's worth bearing in mind that the 'unified api' uses different native data types which may require some work arounds depending on the current structure of your original code.
The biggest point is what I mentioned earlier, in Apples App Store if you linger behind in terms of keeping your app up to date with the latest SDK, API, or anything else Apple decide to upgrade, then it is akin to giving up on that application.
I've put together some links below that may aid you in the migration process:
Native Types - Describes the new native data types that you will need to use in a Unified API app.
32/64 bit Platform Considerations - Considerations in choosing 32-bit and 64-bit modes for your application.
Updating Existing iOS Apps - Follow these steps to update an existing Xamarin.iOS app to use the Unified API.
Binding Objective-C Libraries - This document describes the process used to create C# bindings of Objective-C APIs and how the idioms in Objective-C are mapped to the idioms used in .NET.If you are binding just C APIs, you should use the standard .NET mechanism for this, the P/Invoke framework.
Binding Definition Reference Guide - This is the reference guide that describes all of the attributes available to binding authors to drive the binding generation process.
Updating UI Components - This is a guide to the process for updating UI componenets to the latest versions within the unified api.
I wrote SIP client to register my phone, and make and receive SIP calls. I am able to successfully implement it in Android phones. But the ultimate aim is, I need to implement this for Android watches using Android wear 2.0. Before flashing the watch with Android wear 2.0 image, I tested with Android wear 1.x and found that SIP Api support is not there for 1.x. As the preview image will void the watch warranty, I wanted to make sure what features can work on Android wear 2.0 before starting the implementation. When I searched for, I don't see anywhere that SIP API support is in Android Wear 2.0. Can someone confirm whether Android wear 2.0 has support for SIP or not? Thanks.
It seems that SIP API is not supported (or maybe not yet?) in Android Wear. From this documentation:
Note: Not all Android-powered devices support VOIP calls using SIP. You should always call isVoipSupported() to verify that the device supports VOIP calling and isApiSupported() to verify that the device supports the SIP APIs. Your application must also request the INTERNET and USE_SIP permissions.
I'm not sure with this since I don't try yet, but according to this SO answer, you can use 3rd party SIPStack implementation to make SIP supported.
You can find in this link the only features that Android Wear 2.0 supports.
I'm trying to learn something about iBeacon and I have a question:
As far as I understood Apple provides API in order to develop iBeacons app since IOS7, but for android how does it work? The only thing I found is that It works only from version 4.3 (Is it correct?) But are there any sdk or library to use?
Yes, you can use the open source Android Beacon Library, which gives Android the same basic capabilities to detect and transmit as beacons as provided by CoreLocation on iOS devices. This library is designed to be vendor neutral, and works with a wide variety of beacons. There are also a number of proprietary Android SDKs offered by beacon manufacturers, some of which harness special features that only work with those beacons.
The main thing to understand on Android is that while 4.3+ devices can all detect Bluetooth LE transmissions, there is no native beacon framework, and working with beacons typically requires quite a bit of logic beyond reading the Bluetooth LE packets they send out. As a result, Android beacon apps typically bundle a small library like mentioned above with the app to provide beacon detection and/or transmission capability.
Full disclosure: I am the lead developer for the Android Beacon Library.
You can use as well kontakt.io Android SDK which handles Beacons with IBeacon profile. In the latest release some optimizations in terms of battery consumption were made. Additionally, it supports filtering and modes (Android Lollipop and upwards) according to which scan is performed (explanation in brief here).
To start, visit http://docs.kontakt.io/android-sdk/quickstart/ and follow the instructions.
There is a sample app demonstrating SDK functionalities here. I suggest observing the project as it is the first place where new changes are being introduced.
As #davidgyoung pointed, there is no native framework for IBeacons in Android at the moment.
Background: This is for a university managed lab environment. Upper management wants to know how often users are using the various software we purchase for the labs. I've already implemented a solution for our Windows machines which consists of a client that tracks user process invocation and sends the results to a web service.
Now I need to create an equivalent Mac client but I have zero experience developing for the Mac platform and its various APIs. Our Macs are currently running 10.4, but will eventually be moving to 10.6 within the next year. I think I've got a handle on consuming the web service using something like gSOAP or even Mono. For the process tracking, I was looking at the Carbon Event Manager. But I've been reading that the Carbon APIs are on the road to being deprecated and I'd rather find something that will be supported moving forward.
Should I just use the Carbon stuff for as long as it works? Or is there some equivalent library I could be using that won't be phased out anytime soon?
Carbon APIs are not being deprecated, Carbon applications are. Feel free to use the event manager.
See The myth of Carbon’s 64-bit unavailability