I am working on a universal application, and I am trying to detect whether it runs on a desktop computer or on a real IoT device (Raspberry PI 2). Following the recommendation, I am trying to use API contract checks, however this returns true even on the desktop machine:
ApiInformation.IsApiContractPresent( "Windows.Devices.DevicesLowLevelContract", 1, 0 );
Obviously when I try to call GpioController.GetDefault(), it fails on the desktop, but strangely with a FileNotFoundException: "The specified module could not be found."
So what is the right way to detect a real device?
Thanks for your help,
György
Edit:
On some desktops GpioController.GetDefault() returns null, while on other machines it fails with FileNotFoundException.
Edit:
My goal is to ensure that I can safely call any GPIO or IoT Core specific APIs without using try-catch blocks everywhere to handle exceptions when running on a non-IoT device.
You can find the type of device your app is running on by
Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily
Source:
https://msdn.microsoft.com/en-us/library/windows/apps/windows.system.profile.analyticsversioninfo.aspx
Microsoft does suggest to maximise your reach with universal apps by checking for capabilities instead of just checking the device family.
There's an article about all that here:
https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx
It depends on what aspect of a "real device" you want to check. Using API Contract information is not a good proxy, as you have found (although it should return null, not crash, on desktop -- that's a bug). Using AnalyticsInfo can be a reasonable proxy but you have to be careful about receiving new values over time, plus it actually identifies the OS type rather than the physical hardware. Enumerating hardware devices is the best way to detect hardware, but they can come and go dynamically as the user plugs and unplugs them.
What is it you are looking to do differently based on the answer?
Related
Upon upgrading to Big Sur (macOS 11.0.1), our app is now asking the user to grant permission to use Bluetooth. However, we are not running any bluetooth code to my knowledge. We do link to CoreBluetooth, but it's been like that for a long time, and this prompt has not appeared.
When running in Xcode 12.2 it does crash with this message:
2020-11-13 13:21:58.685610-0800 Fuze[31049:200367] [access] This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothAlwaysUsageDescription key with a string value explaining to the user how the app uses this data.
But to my knowledge, NSBluetoothAlwaysUsageDescription is only applicable for iOS devices.
I suspect this is something new with Big Sur, because the System Preferences UI for Security & Privacy -> Privacy, did not have a Bluetooth section in Catalina, and it does in Bug Sur. But the Apple documentation does not make mention of this key being applicable for macOS.
https://developer.apple.com/documentation/bundleresources/information_property_list/nsbluetoothalwaysusagedescription
So my questions are:
Is this key now applicable for macOS and we should have it, even though the documentation says it's only for other platforms, or is there a different key for bluetooth for macOS? I haven't found one.
Is there a way to control this prompting or not, because we aren't actually using the bluetooth code. We need the framework for a particular feature, but it's not applicable for many users, so it's confusing to ask permission for it right when the app launches.
Thank you!
I'm not confident about this, but I've been running into some Bluetooth on Big Sur strangeness today as well. In my case, I run a Bluetooth peripheral from the Terminal, and I was also recently prompted to provide the Terminal with Bluetooth permission (which I'd never seen before).
For testing purposes, you can try the "Privacy — Bluetooth Peripheral Usage Description" or "Privacy - Bluetooth Always Usage Description" - and see whether that resolves the crash (I assume it would). It's strange, as I didn't think either of these were required in the past - but it looks like Big Sur is definitely cracking down on permissions.
When you go to "Signing and Capabilities", if there is an option to enable "Hardware -> Bluetooth" in the "App Sandbox" - I would try that out too (you may also need to enable Location, but I can't recall). I'm curious if modifying that flag would change anything regarding permissions.
When you link to CoreBluetooth, are you using the API at all? Because the permission check should happen on the first API call. But, Bluetooth is weird, so it might kick in as soon as the app launches...
In thinking about it, I've actually never optionally used Bluetooth in an app - it's always initialized from app start, so I can't say when the permission check occurs.
I have been working with web-bluetooth for the past several months on iOS and ChromeOS without any problems. But today, I tried to run some of my examples on Windows for the first time, and to my surprise, most of the things I had implemented didn't work with Windows. I am able to successfully connect to my peripheral, but whenever I try reading or writing anything to a custom service with a custom characteristic, I get the error "GATT operation not authorized". I have tried looking around but there is no information anywhere about this.
I am including below the simplest example I have which is just for turning the LEDs on / off on an nrf52832 board. There is only one custom service and one custom characteristic implemented, the value of which controls the states of the LEDs. This works without any problems on Chromebooks and Macs but does not work on Windows. Here is the link to this simple project including the embedded code and the web-app.
https://github.com/shtarbanov/WebBluetooth-Feather-nRF52832/tree/master/LED%20Control
I have made two implementations of the same thing, one based on promises and another based on async-await located in the folders "WebApp (Async)" and "WebApp (Promises)", respectively. Both of those implementations work fine on Mac and Cromebook, but not on Windows.
It is a known issue that secure characteristics are not accessible using Web Bluetooth on Windows. On other platforms the pairing occurs automatically, but not on Windows. There is an issue tracking this:
https://bugs.chromium.org/p/chromium/issues/detail?id=960258
Stuck with this also and as for workaround i can recommend for windows platform to pair device firstly using windows itself and than to pair it via browser(as a workaround). Not much but hope this helps, at list a little.
P.S. it should be paired via windows only once, so PC will remember device, and than you can pair via browser as long as PC remembers device.
I'm posing a question here directly in relation to this issue on github for node-serialport. In a nutshell something that used to work fine in v4.x of the library no longer works in v6.x of the library. I think it must have something to do with how the library is opening the COM port (options or something), and I suspect its artificially limiting the power delivered over USB in the current version of the library.
I wrote the simplest scripts that I could to reproduce the problem (scripts posted in the issue) using:
NodeJS and v4.x of the library [works]
NodeJS and v6.x of the library [fails]
Python and PySerial equivalent [works]
Following through on a recommendation by the repository maintainer, I researched and found a utility for windows called drstrace that allowed me to capture logs of the execution of each of these scripts executing for a period of time (these logs are posted as attachments in the referenced issue).
Now I'm stuck, as I don't know how to make heads or tails of the drstrace logs, though I feel confident that the difference is probably evident in comparing the three files. I just don't know enough about how to read the drstrace logs and windows drivers and system calls to break through.
I realized posting this question here is something of an act of desperation, but I figure it's worth a shot. Hopefully it is clear that I've not lacked in effort pursuing this on my own, I'm just over my head at this point, and could use help getting further. Any guidance would be appreciated. Most awesome would be someone who is versed in this level of diagnostics giving it a look and reading the tea leaves. It would be great to contribute back to such an important open source library.
Update 2017 Nov 10
I reached out to FTDI support asking:
I use the FT231X in many of my products. I need some help with
understanding how the Windows FTDI driver manages power. More to the
point, I'm hoping you can help me understand how to direct the driver
to allow the full 500mA allowed by USB to be delivered to my product
by a Windows computer.
The reply was:
Just use our FT_Prog utility to set the max VBUS current to 500
mA:
This drive current becomes available after the FT231X enumerates.
I haven't tried this advice yet, but I wanted to share it with anyone reading this. The fact remains that node-serialport 6.0.4 behavior differs from both node-serialport 4.0.7 behavior and pyserial behavior.
Here is an alternative theory you could look into:
Windows interacting with V6.x might be interacting with the flow control settings differently, which might be causing your device to respond with an unexpected state causing your test to fail.
I Read a bit more about windows drivers and how they manage that i only found out that its related to the hardware manufacturer i think its not a fail from serialport it self since its really using the drivers it self it adds no extras on that level.
i am Contributor of SerialPort and can tell you that it offers only bindings for the Operating System to node that means it don't does any actions it offers you only a API read the following from microsoft they say you should ask your hardware vendor
Power Management in Serial Port Drivers (Windows CE 5.0)
Windows CE 5.0
Send Feedback
The minimum power management that a serial port driver can provide is to put the serial port hardware into its lowest power consumption state with the HWPowerOff function, and to turn the serial port hardware fully back on with the HWPowerOn function. Both of these functions are implemented in the lower layer. Beyond this minimal processing, a serial port driver can conserve power more effectively by keeping the port powered down unless an application has opened the serial port. If there is no need for the driver to detect docking events for removable serial port devices, the driver can go one step further and remove power from the serial port's universal asynchronous receiver-transmitter (UART) chip, if no applications are using the port.
Most serial port hardware can support reading the port's input lines even without supplying power to the serial line driver. Consult the documentation for your serial port hardware to determine what parts of the serial port circuitry can be selectively powered on and off, and what parts must be powered for various conditions of use.
Source:
https://msdn.microsoft.com/en-us/library/aa447559.aspx
about changes from serialport v4 => 6
new Stream Interface
but nothing changed with the core opening method of the port.
also nothing changed in the bindings which open the port
node serialport is a collection of bindings written in c++
Since I am new to Windows Phone Technology, I want to programatically find in my application that windows device is rooted/jailbrake or not. I found many links but it seems like no way for finding rooted windows device programatically. So is there any way to find rooted/jailbreak windows device programatically any API available for this ? Can anyone help me ?
Thanks
Rooting and/or jailbreaking is not officially supported by Microsoft and therefore there is no official way for you to check if your application is running on such device.
In principle, you could check that, but that check would involve adding stuff to your application that would not pass the certification which means that you can run that application only on jailbroken device.
Which then means that you don't need to check at all since you already know that you are running on such hardware.
We have a registered PC based application that needs a Dongle (hardware that gets plugged on the printer port) to start and execute. The vendor who provided us this application and Dongle, does not make or work with these dongles any more, since they are very old technology, and would not help us in this aspect.
So my question is --> is it possible to read the security code from this Dongle and store it in a file or something on the PC. We also do not have the source code of the application. Can we change the call in the application to read the security key from this file instead of trying to read it from the Dongle attached to the printer/parallel port.
Sorry for the vague question but we are very desperate to get help on this problem as out application has 16-bit code and it would not be supported by Windows 7 which is 64 bit. Thanks!!
The LPT security devices don't just contain information but usually include a processor and perform certain operations. Dongle emulators were developed when dongles where more widespread, but as they were based on reverse-engineering, they didn't work exactly right.
To answer your question, no, what you need is not possible. You need to start thinking about migration to another application. A temporary solution would be to have a copy of older OS running in virtual machine and to have your application run in this virtual machine. Such solution will work for another 5-10 years for sure, and I think it's enough for migration.