I need to find out if I could shut down enrolled device using G-Suite MDM? There are some solutions however I couldn't find anything about that in G-Suite.
You can factory reset a managed device from the console at admin.google.com, it removes all the data from the device.
If you just want to power off the device without removing the data, then I don't think it's possible with the Google MDM.
Related
Are devices on Amazon Web Services device farm real?
I was just curious that where those devices are placed and how can they work simultaneously for thousands of users?
Some of this is covered in the Device Farm FAQ, e.g.
Q: Does AWS Device Farm use simulators or emulators?
AWS Device Farm tests are run on real, non-rooted devices. The devices are a mixture of OEM and carrier-branded devices.
Q: How do you clean up devices after my testing is completed?
After test execution completes, we perform a series of cleanup tasks on each device, including uninstallation of your app. If we cannot verify uninstallation of your app or any of the other cleanup steps, the device will be removed and will no longer be available.
While we continue to add additional cleanup steps and improve the cleanup process, it is possible for data to persist between sessions in some cases, especially if you make use of the device system outside the context of your app. For this reason, and because AWS Device Farm captures video and logs of activity taking place during your use of each device, it is recommended that you avoid providing or entering sensitive information such as account info (E.g., Google Account, Apple ID), personal information, and other security-sensitive details during your automated test and remote access sessions.
I recommend visiting that page and reading the entire FAQ.
The actual mechanics of how Amazon provisions Device Farm devices probably aren't available publicly.
Now I face a tricky problem. My Blackberry Classics has a black screen problem. When I connect it to my laptop with USB cable, Blackberry Link can detect it. However when it tried to connect to it, the Blackberry Blend prompted me to set the Allow Connections switch to on on the device. Obviously, I could not do that. I am thinking maybe there is a method to let me connect to the Blackberry 10 through the USB port just like a console port, but I am not sure. Does anyone know about it? Thanks in advance.
Momenitcs does provide a few ways to connect with a device. But generally the device has to be in development mode, which requires interacting with the device which you apparently can't do. The access is also limited to the development user so you could not use it to, for example, access data from installed applications.
About the only thing you can do at this point is use link to backup your data and restore to that phone once repaired, or to a new phone.
Also, since this question is not really suitable for StackOverflow I'm going to flag it for closing. Questions like this properly belong on SuperUser http://meta.superuser.com/questions/4836/what-is-the-difference-between-super-user-and-stack-overflow/4838
I am building an app where I do not want a loginsystem. I still want to be able to know what user is sending information to my online database. As far as I know, the UDID is not allowed to upload to any servers, so that is out of the question. Can I use the iphones mac address for this? If it is dynamic, it will change from time to time, and I won't be able to track it.
We use the MAC address as a unique identifier now the UDID has been deprecated.
MAC addresses are hardware based and therefore cannot be changed.
I understand that some applications need to check against a server periodically, but why don't servers let a mobile device know when it's time to update.
For example, let's say you receive an e-mail in gmail. As it stands now, there can be a delay between receiving the e-mail and your device notifying you. I assume this has to do with waiting until the device has checked the gmail server, at which point it sees the new e-mail and notifies the user. It makes more sense to me that when the gmail server receives an e-mail, it should ping (or however the creator wants to implement it) all registered devices to let them know that it's time to update. This way notifications would be synchronized and mobile device could save battery by not having to periodically check a server.
What you are describing is called a "server push". Some mobile applications does use server push. And Google actually have a technology in place to make this easier to implement, named "Cloud to device messaging" (C2DM). It works by having the servers sending a tiny little message, via googles C2DM servers, to the application running on the device, informing it its time for a update. And the device then retrieves the actual update from the original server (not from C2DM).
Its good stuff. It allows the service listening for C2DM manages to wake up the phone and everything. The downside is, the user of the application needs a google account. For android users, this isnt really a downside though.
Except they do, in some cases. In the "Mail, Contacts, Calendars" section of Settings on my iPod, there's a submenu labeled "Fetch New Data", which contains an option to have the mail server or whatever "Push" the data to the iPod. The Fetch aspect, which you can set the schedule for, is for when Push is off or you're syncing with applications that don't support push.
That is how Android does it. It pushes notifications to the device and that api is open to third party developers as well so they can push notifications to their users.
That thing is it is difficult to know the address of a mobile device at any particular time, the I.P address is dynamic, on a server the address is much more stable, so the device knows it will always find Google at google.com but Google has no real way of knowing where to find the device, it wouldn't know where to ping in the first place.
This is where push comes in, there are different implementations but i think they work by having the device maintain a connection to the server, and reestablishing it if its lost.
See http://en.wikipedia.org/wiki/Push_technology
This of course is much harder to implement and maintain then a simple client pull.
When Apple's Remote app tries to connect to a Mac (running iTunes) on a local network (using WiFi), the user needs to enter a passcode provided by the iPhone as a security measure. This approach has been adopted by a number of other apps (e.g., Rowmote, Pastebot, ...). Is there an API that provides this way of working?
Assuming Bonjour is in play, how does an iPhone checks if the passcode entered on a Mac is correct without resolving the NSNetService the Mac is publishing? Or does the iPhone resolve the NSNetService a Mac is publishing and waits for the passcode to be confirmed before processing any other packets that might be sent via the NSNetService (packets other than the passcode).
I have a solution for my problem, but I would like to know if there's an API I have overlooked that provides a ready-made solution.
Advice and pointers are welcome.
Thanks in advance,
Bart
I don't believe there is an Apple provided API for this. I simply use the Bonjour APIs to open a connection between two devices, then have one randomly create a 4 digit passcode and ask the other device for it. The other device presents a UI to ask the user for the passcode, then transmits it back and waits for an answer. If they match, the devices store each other's identifiers to skip over this process the next time they connect.
Edit: Thanks to tc for pointing out that this implementation isn't totally secure. I'm now having one device create a unique, random password, and send it over to the other device, then store the SHA1 hash of the password for future reference. Then the other device stores the password and sends it back over whenever it connects for authentication. The user does the number code thing once in order to let the devices know that they should trust each other in the future, but now in order for a reverse engineer to connect to a device they would have to know both the identifier of and password for a valid, connected device. (Or they'd have to have access to both devices and do the number code thing; there isn't really a way to stop anyone from doing that, obviously).