How to get the device platform on Windows 10 - windows-phone

Since one release binary will run on pc, xbox and phones, I need a way to fetch the device type on runtime.
It is doable by checking with the ApiInformation for present types, methods etc., but I believe there should be a more reliable way.

Currently (with the preview tools released 23-Mar-2015) there isn't an easy way to do this, other than (as you mention) using the ApiInformation methods to detect implementations of things that only exist on the specific platform you're after.
It would be nice if there were some helpers to do this and if none are in the final tooling I'm sure some will be created by helpful people in the community.
However, there is a really good reason not to have this in that it encourages broad assumptions about the device.
If it was possible to say "Am I running on a phone?" then if you got the response 'Yes' then it would be easy to make assumptions about what was possible with that device but not all phones have the same capabilities.
It looks like there will be a "mobile" version of Windows 10 for both phones and small tablets. If you were able to say "am I the 'mobile' version?" then again that wouldn't potentially answer all your questions and you'd have to still check individual API availabilities as the capabilities of a cheap tablet and a high end phone could be vastly different. (The inclusion of physical buttons on the device and the ability to make phone calls are two obvious examples.)
Extending this further there are plenty of scenarios where you'd treat different platforms the same as the functionality exists on all of them. In this scenario you're code would be better of saying "Is such and such API available?", rather than saying "Am I running on desktop, Xbox or SurfaceHub?".
The IOT platform will likely further complicate this due to the range of functionality and capabilities different IOT devices will have available.
There are very few scenarios where you want to know the platform you're running on and not whether a specific API is available. Hopefully, by only exposing API availability Microsoft are encouraging developers to think about checking for what they actually need, rather than relying on broad, potentially incomplete, classifications of devices.
Just as with web development where you don't know what platform or browser you are running on, you shouldn't detect the platform and make assumptions about what capabilities that device will therefore have, you should detect if the specific capability you require is supported/enabled on the device before using it or exposing associated UI in your app.

It seems there is a new API to detect Device Family:
Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily
You can find more information here: https://msdn.microsoft.com/en-us/library/windows/apps/dn705767.aspx
Updated:
https://msdn.microsoft.com/en-us/library/windows/apps/windows.system.profile.analyticsversioninfo.aspx

[Edit July 3 to replace //build-era information with current information]
Although you can try and infer the device you're on by using the ApiInformation APIs to detect APIs, this is a very bad solution since APIs can be added to devices over time. Please don't do that; your future self (or your replacement ;-) ) will thank you.
If you really do need to programmatically detect the device family that you're running on (and in most cases you don't) then you can use AnalyticsInfo.VersionInfo.DeviceFamliy. This returns a string for which there is no published standard set of values, because device families could be introduced or retired at any time.
If you want to provide different resources per device-family (strings, images, XAML files, HTML pages, etc.) then you don't need to detect the device-family in code; instead you can use an MRT qualifier DeviceFamily (such as Logo.DeviceFamily-Mobile.png). Just make sure you always have a fallback resource (image, string, etc) for use when the app is running on a device family you've never heard of before. And don't fall into the trap of assuming things like "Desktop requires higher-res assets than Mobile" because that is often not true.

Additionally to support the scenario Alan describes in his comment you can check for a Contract rather than a specific type as this indicates a block of related functionality. There is one such contract for the Windows Phone specific APIs - I described in here http://inthehand.com/2015/03/26/determine-if-running-on-windows-phone-from-a-uap-application/
Since this contract provides compatibility APIs for current Windows Phone apps we can assume at this point that it won't be implemented in small tablets as they won't have this. Obviously since the OS or APIs are not final this is not set in stone yet. This is a useful thing to know for Windows Phone especially if during the transition you want to cross promote legacy WP apps only on WP devices. For custom IoT devices I would check availability at the API level.

You can specify device family exclusive resources and views using specially named folders: (http://www.sharpgis.net/post/2015/04/01/Creating-DeviceFamily-specific-layouts-in-a-Universal-App).
You could, for the "advertising only same family apps" scenario described above, place a JSON or XML file in that device family's folder and fetch it at runtime using the storage API's.

I use this for phone (mobile):
if (Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Mobile")
{
// code for phone
}
else
{
// other code
}
extample is here

This is just repeating one of the previous answers which suggests using Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily but I thought I'd include the complete code for a check:
// ----------------------------------------------------------------------
// IsRunningOnXbox
// Determines whether or not the game is running on an xbox console
bool IsRunningOnXbox()
{
// Skip if already checked
static bool bChecked = false;
static bool bRunningOnXbox = false;
if (bChecked)
return bRunningOnXbox;
// Retrieve the platform device family
Platform::String^ strVersionInfoDeviceFamily = Windows::System::Profile::AnalyticsInfo::VersionInfo->DeviceFamily;
if (strVersionInfoDeviceFamily != nullptr)
{
// Check to see if the device belongs to the xbox family
std::wstring strDeviceFamily = strVersionInfoDeviceFamily->Data();
std::transform(strDeviceFamily.begin(), strDeviceFamily.end(), strDeviceFamily.begin(), ::tolower);
if (strDeviceFamily.find(L"xbox") != std::wstring::npos)
bRunningOnXbox = true;
}
// Check complete
bChecked = true;
// Return whether or not the host platform is xbox
return bRunningOnXbox;
}
I do agree with Chuck's comment that this is probably not what AnalyticsInfo is intended for... but at the same time, we're talking about the xbox - a device with a single manufacturer who is also responsible for the OS. So in my mind at least, this seems pretty safe. Plus, if you wrap it like this, it's incredibly easy to swap in a different check should something better come along.

Related

Applying Non-Standard Power Assertions & Creating Virtual HIDs

I've got a big ask here, but I am hoping someone might be able to help me. If there's another site you think this should be posted on, please let me know.
I'm the developer of the free app Amphetamine for macOS and I'm hoping to add a new feature to the app - keeping a Mac awake while in closed-display (clamshell) mode while not having a keyboard/mouse/power adapter/display connected to the Mac. I get requests to add this feature on an almost daily basis.
I've been working on a solution (and it's mostly ready) which uses a non-App Store helper app that must be download and installed separately. I could still go with that solution, but I want to explore one more option before pushing the separate app solution out to the world.
An Amphetamine user tipped me off that another app, AntiSleep can keep a Mac awake while in closed-display mode, while not meeting Apple's requirements. I've tested this claim, and it's true. After doing a bit of digging into how AntiSleep might be accomplishing this, I've come up with 2 possible theories so far (though there may be more to it):
In addition to the standard power assertion types, it looks like AntiSleep is using (a) private framework(s) to apply non-standard power assertions. The following non-standard power assertion types are active when AntiSleep is keeping a Mac awake: DenySystemSleep, UserIsActive, RequiresDisplayAudio, & InternalPreventDisplaySleep. I haven't been able to find much information on these power assertion types beyond what appears in IOPMLibPrivate.h. I'm not familiar at all with using private frameworks, but I assume I could theoretically add the IOPMLibPrivate header file to a project and then create these power assertion types. I understand that would likely result in an App Store review rejection for Amphetamine, of course. What about non-App Store apps? Would Apple notarize an app using this? Beyond that, could someone help me confirm that the only way to apply these non-standard power assertions is to use a private framework?
I suspect that AntiSleep may also be creating a virtual keyboard and mouse. Certainly, the idea of creating a virtual keyboard and mouse to get around Apple's requirement of having a keyboard and mouse connected to the Mac when using closed-display mode is an intriguing idea. After doing some searching, I found foohid. However, I ran into all kinds of errors trying to add and use the foohid files in a test project. Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app? I'm not asking for code help with that (yet). I'd just like some help determining whether it might be possible to do.
Thank you in advance for taking a look.
Would Apple notarize an app using this?
I haven't seen any issues with notarising code that uses private APIs. Currently, Apple only seems to use notarisation for scanning for inclusion of known malware.
Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app?
Taking a quick glance at the code of that project, it's clear it implements a kernel extension (kext). Those are not allowed on the App Store.
However, since macOS 10.15 Catalina, there's a new way to write HID drivers, using DriverKit. The idea is that the APIs are very similar to the kernel APIs, although I suspect it'll be a rewrite of the kext as a DriverKit driver, rather than a simple port.
DriverKit drivers are permitted to be included in App Store apps.
I don't know if a DriverKit based HID driver will solve your specific power management issue.
If you go with a DriverKit solution, this will only work on 10.15+.
I suspect that AntiSleep may also be creating a virtual keyboard and mouse.
I haven't looked at AntiSleep, but I do know that in addition to writing an outright HID driver, it's possible to generate HID events using user space APIs such as IOHIDPostEvent(). I don't know if those are allowed on the App Store, but as far as I'm aware, IOKitLib is generally fine.
It's possible you might be able to implement your virtual input device using those.

How do I blacklist certain applications in OSX programmatically?

I am trying to develop some software similar to selfcontrol (it blacklists certain websites for a certain amount of time). However, I want to be able to do this with applications on OSX (for example, a person would have to answer some math questions before accessing the MineCraft App).
Is there some sort of parental control API in the OSX SDK? I'm familiar with some kernel development, but I'm just looking for a starting point of where to look.
System preferences does include parental control options. Search for com.apple.familycontrols to find options for how you can interact with the available settings.
I don't believe there's any high level API that allows you to do this.
However, as you state you're familiar with Kernel development, that's the way to go and indeed it's how the parental controls work; with a kernel extension (kext).
This article explains about 4 scopes of interest for authorization in the kernel. You'll need to write a kernel extension and monitor the VNode scope, which will inform your kext of all vnode access by calling a function defined in your kext. This function must then return one of either Accept, Deny or Defer. If you call Deny on access to a vNode that is making an Execute operation, then it will be blocked.
Finally, if you're going to write any kernel code, then I recommend you get a copy of this book, which includes example code based around monitoring the vnode scope.

Is there a comprehensive list of Device information available through WinRT?

There are things I want to know about the device. Is it ARM or Intel? Does it support Bluetooth? What version of Windows is the user running? What is the resolution of the device? What is the IP of the device. Things like that. And, I know not everything is available. Instead of a question for every single information datum, is there a comprehensive list (or even a demo) that shows what is available?
You can use DeviceInformation.FindAllAsync() to list cameras, mics, audio output devices and external storage. For Accelerometer I think you need to catch exceptions when you try to use one. I doubt there is something to check for ARM/Intel or Windows version, although you can compile separate builds for ARM/Intel and use #defines to check the difference. For screen resolution I would use something like Window.Current.Bounds (assuming you are in full mode). IP, Bluetooth are probably things you might check in their own stacks (never needed those, so not really sure where). I haven't seen a demo that would show all these, but it sounds like something that might be worth adding to the toolkit...

Camera compatibility

I have an usb-camera with its drivers and dll with some functions to use this camera in my solutions. I want to use it in any wide-spread applications, to be able just to choose and use it in Skype, for instance. So. I want to develop something that will allow me to use this device as usual web-camera.
I've heard something about such technologies as "Upper-Level Filter Drivers" and "user-mode DirectShow source filter". Looks like it something that can help.
So the question is: what technologies exist for such tasks? What technology should I choose to solve my problem if I have no skills of driver development?
Skype still uses DirectShow for video capture and user mode filter will do the job. Still Skype makes certain unreasonable assumptions that limit compatible source filters, such as if the developers stopped development/testing as soon as they had their favorite USB cam working and ignoring all other devices users might possibly want to attach.
One of the options you were suggested (in Russian - 1, 2) was to develop a kernel mode driver so that your device is visible to apps through standard WDM Video Capture Filter. This is possible and would work, though in my opinion it is a huge overkill.
Fitting custom source filter is not easy because Skype does not like a debugger attached, however driver development is really a completely different story.
The Skype Forum link you refer to is clearly misleading. The poster complains that Skype update broke compatibility with video sources. And response from admin is about audio devices, and is irrelevant.

What is the most reliable way to determine the OS of a visitor to a web site?

What is the most reliable way to determine the OS of a visitor to a web site? All other things being equal I prefer an easier to integrate solution. I'm not attempting to gather analytics and I understand there is no completely reliable method. The purpose of this is to subtlely tailor the user experience in ways that do not affect the functionality of the site -- for instance, making a guess at which os version of a cross platform app the user would like to download (I won't hide the other selections, the one matching the user's OS will just become more prominent).
On the client side, you can use Javascript to try to detect it:
// This script sets OSName variable as follows:
// "Windows" for all versions of Windows
// "MacOS" for all versions of Macintosh OS
// "Linux" for all versions of Linux
// "UNIX" for all other UNIX flavors
// "Unknown OS" indicates failure to detect the OS
var OSName="Unknown OS";
if (navigator.appVersion.indexOf("Win")!=-1) OSName="Windows";
if (navigator.appVersion.indexOf("Mac")!=-1) OSName="MacOS";
if (navigator.appVersion.indexOf("X11")!=-1) OSName="UNIX";
if (navigator.appVersion.indexOf("Linux")!=-1) OSName="Linux";
document.write('Your OS: '+OSName);
Sourced from here. Javascript methods are inherently unreliable however. Server side, you can examine some of the HTTP headers in the language of your choice, however, these can also be crafted and are unreliable as well.
In short, there's no 100% reliable method.
There is no reliable way to do it, and it's not only none of your business, it's also something your web site should pay no attention to.
If this was something your site was meant to know, then there would be a navigator.os property. Note there is not.
Here are examples of Perl code that does OS detection server-side from useragent strings:
HTTP::BrowserDetect or HTML::ParseBrowser for desktop operating systems
Mobile::UserAgent for legacy mobile platforms
What is the most reliable way to determine the OS of a visitor to a web site? Ask them on a survey... all else is a crap shoot. Using the UserAgent string you may be able to divine the OS, but as numerous articles will attest - there is no really reliable way to tell.