When I enumerate Bluetooth LE devices using WinRT API, sometimes, I needed to reset Bluetooth radio to successfully find my device. I am wondering is there an easy way to do this from code (Windows SDK, WinRT, WMI etc)?
After digging through Windows Universal samples from Microsoft, I have found a sample RadioManager which shows how to access Radios and turn ON/OFF from code at will. I was able to use the API successfully with a caveat that when used from Desktop WPF app, the app has to be built to match native architecture of the machine. Otherwise, ‘GetRadiosAsync’ method returns empty set.
I'm not totally sure, but resetting the system-wide Bluetooth radio is the sort of action highly unlikely to be available to an execution environment with non-admin privileges.
Anything able to stomp over the abilities of other processes (like turning off a radio) is not going to available in WinRT.
Edit: I stand corrected. Such an API apparently exists:
Windows.Devices.Radios.SetStateAsync
Related
I've written a simple web app to factory-reset bluetooth devices that were accidentally turned on during shipping. The app scans for a class of bluetooth devices (those made by the company I work for), renders a list of devices found, and, when I click a button next to a device in the list, sends a reset message to the device.
This is a very manual process and I'd like to automate it. The problem is the Chrome dialog that asks for permissions to pair with a device. I am trying automate the app with Puppeteer, but I can't find a way to either (a) programmatically grant permissions to pair with a device or (b) to select the device in the dialog and click the "pair" button via Puppeteer. Anyone know if what I'm trying to do is possible, or if there's a better way to achieve the goal? Thanks!
This is not possible in Chrome. (I work on chrome.) The automation that does exist for Chrome's testing is layered such that actual Bluetooth connections aren't made.
Eventually we would like to enable this workflow via Enterprise configuration controls. But that is not started yet and there is no date commitment.
One alternative is to use node.js, though you lose the easy interface. You might build the reset backend in a node server and have it serve a web page interface.
I'm developing a line of business app for Windows 8.1, that is, I am not deploying through the Windows Store and will be able to control all of the features of both the OS and hardware this app is being deployed on.
Because this app is working as the UI in a real-time situation I would prefer if I could ignore the life-cycle events and not have the app suspend or terminate at the whim of Windows 8. Does anyone know of a way to do this?
I have seen some older answers, such as this one and this other one indicating otherwise, but I haven't yet found anything more recently and specifically dealing with the case of a line of business app. I have found the Embedded Lockdown Manager which would prevent the app losing focus and addresses some of the needs I have, but I still would like a way to simple disable Lifecycle events.
Have you tried Assigned Access Mode? Basically use PC Settings -> Accounts to lock an account to a single app. You have to reboot the device and log-in again in order to run anything else.
I'm working on a Windows phone application which uses Network and Location capabilities.
All apps using any kind of these capabilities or others, will first display a consent dialog ("this app will use microphone, do you allow this?").
This dialog appears on first use by default on the Windows Runtime apps. But what about the apps for Windows Phone (Universal app, still using WinRT)?
Should I display a dialog for the first time usage of the capability or the OS handles this automatically? In Debug mode, nothing ever appears. I've also tested the app in Release Mode, and still nothing. So, do we have to manually handle this or the OS will handle a display of such dialog when the package is to be installed and used on other devices?
You can trust that the operating system will do the right thing for user consent when you declare a capability such as location. On Windows, as you've seen, this consent prompt happens on first run. The model for Windows Phone is to ask for consent at installation time. Either way, the system will take care of the prompting for you--you need not implement your own prompt.
Indeed, if you think it through more carefully, what would you do with the accept/decline answer from such a custom prompt? The whole purpose of the consent prompt is to broker access to sensitive WinRT APIs, which means those APIs will fail unless consent has been granted. Apps can't be given the power to make that decision on their own, because it would defeat the whole purpose of consent. Thus even if you obtained accept/decline yourself, there's nothing you could do with that value; there's no API to set permissions programmatically, as only the user can do that through Settings.
The consent prompts are just a way to initialize those permission settings at the appropriate time, and again, you can trust the system will do the right thing.
Windows Phone universal apps uses WinRT APIs as well, and same general guidelines described below applies to Windows Phone as well. However, there are differences in settings charm . The best way for you to test is publish the windows phone app as beta, then see if there is a consent prompt.
http://msdn.microsoft.com/en-us/library/windows/apps/hh768223.aspx
I need to know if it is possible to emulate certain functions of the ChromeOS Management Console through apps.
Basically, I want an app to be able to control certain aspects of the OS without being required to purchase the management console.
I believe there is a way to do it, I just need to know where to start. Can an normal JS extension do it? Pepper app? Native App? Which method will give me access the the settings section of the chrome OS?
Most, if not all, of the functionality provided in the settings section is not available to normal apps or extensions.
That's probably not what you wanted to hear. To officially request the chrome team adds the features you need, go to http://crbug.com and make a feature request. You should include more details about exactly what you're trying to do.
I have created an application which use HERE Application Launchers and my app work fine on my Nokia Lumia 720.
My problem is certification on marketplace I get the response like:
The application exhibits device specific behavior that inhibits functionality and
features. The application's main functionality
cannot be tested on non-Nokia devices because it requires Nokia Here Drive.
-Launch the application on HTC 8X.
...
-Observe the user is prompted to install the app "Here Drive".
I agree with this becouse HERE maps are only available on Lumia devices. But how to use HERE Launchers if we cannot publish it on the marketplace?
If somebody has had similar situation and know solution for it?
That's because it's better to use the ms-drive-to or ms-walk-to Uri scheme!
When you use those, the phone itself will launch HERE drive if it is present, otherwise Bing maps!
Get the needed example code and usage on MSDN here: http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj710324(v=vs.105).aspx
I think you need to clearly state in your app description for Store and in the app itself, that it works only on Nokia devices. (Or you can implement some kind of fallback behavior for non-Nokia devices as well)
This way it should pass the certification, because the behavior will be expected and not confusing.
I suppose either there were something wrong on the submission time, or the rules have changed. I at least submitted an application which is using the Uri Scheme directly, and it got accepted.
In the essense there is no requirements for any specific Application being installed, but there is a query made for applications which support the Uri scheme protocol. And if the HERE application having it is installed, then it will be launched.
And if there is no handlers available, then the market place should be opened for searching for the handlers. At least that's the way the system is designed for.