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.
Related
I'm looking for a way to managing and controlling IoT devices without the (constant) need for a remote server to be part in it and with a PWA instead of a native application on the managing device. The resulting goal is an IoT device that keeps working when a product eventually goes obsolete (no more server running/allocated) and having an application that has PWA benefits like always up-to-date, easy to replicated and cheaply hosted on something like S3.
As an example, let's say I have one or more IoT devices of different classes like an ESP8266 and a Raspberry Pi for instance. Just as with any new IoT device I want to add it to the network and from there on manage its state from an app. The app in this case is a PWA instead of full blown native app.
1) Traditionally, in the initial setup a native app would scan for wifi networks, connecting automatically to one that has the right name. Using PWA's we are limited to just the "state" of the network. So users would have to manually switch to the network of the newly connected IoT device. This is okay.
2) Next up, the user would need to enter his/her wifi credentials. There might be methods to set this up automatically using a native app, but I don't believe this is the case on a PWA. This, also, is okay.
3) The device then restarts, tries to connect to the network set up in (2). If set up correctly it should get its IP using DHCP. And now things get difficult. I want to 'discover' that network from my PWA. There used to be a way to retrieve the IP from a device using the WebRTC API. but that since has changed to show an obfuscated mdns that resolves to localhost. The ip leak would have allowed for a browser based network scan, but that is no longer possible. I always hoped that Android would default to using a users router as a DNS server, but that is not the case. The result is that simply using an mDNS isn't an option either. I do not want user having to check their router, install an app like fing or do anything else that disrupts the flow from a UX perspective.
Step (3) needs to run every time the app starts so you'd want something reliable. Scanning for devices isn't possible using a PWA, so I need to find another method. I was thinking of something like the way Docker containers can find each other in between networks (see etcd for example), using a predefined key that is shared during installation. The problem with this, is that it requires a remote server to store the IPs attached to that key. I don't want that.
Ideas on how to solve this are very much appreciated! I want to be able to offer a solution that would work even when WAN is out. That being said, I am aware that a connection to a remote server is needed if the end user would want to enable any voice assistant or wants to control a device from WAN.
I want to build an application for the Android TV platform. Part of this app is a service/daemon, which must start when the device boots, and must always run when the Android TV is powered on, even in stand-by.
Why do I want this service/daemon to run at all times? Part of my project is an application for portable devices (such as a smartphones and/or tablets), which will send commands via TCP to the Android TV app. Based on the kind of TCP message, the app will perform an action (power device on/off, push my app to the foreground etc.).
I have tried different code examples, but Android TV Oreo just kills this service after a while. I think these code examples were made before the Android Oreo restrictions.
An application like Kodi for the Android TV, has a web service that is always running in the background. Even on Oreo. but I can't figure it out how they have done that. Does anyone have some tips for me?
Edit: Yatse Remote Starter does what I want for Kodi, what I want to do with my app. It starts on boot, runs even in stand-by. https://play.google.com/store/apps/details?id=tv.yatse.android.remotestarter&hl=en. Still I would like to know how, so I can do it myself as well. Thanks in advance!
Many android apps and services are running simultaneously. To lower the chance of problems which cause poor user experience, Android 8.0 apps has two ways to limit what an app can do:
Background Service Limitations: While an app is idle, there are limits
to its use of background services. This does not apply to foreground
services, which are more noticeable to the user.
Broadcast Limitations: With limited exceptions, apps cannot use their
manifest to register for implicit broadcasts. They can still register
for these broadcasts at runtime, and they can use the manifest to
register for explicit broadcasts targeted specifically at their app.
Therefore, you need to create a ForegroundService in order to continue processing of your app. You can check this SO post regarding this issue.
I am struggling to find how to let google home do a local network rest call.
I have some ESP8266 laying around with mDNS and rest api in them.
Now with the google home I want it to send a rest call to the device.
I don't want any web hooks / services like IFTTT. I don't want the communication going through these 3rd party services.
It should work like this google home gets input (google service to understand is oke). It retrieves the action (local network, url rest call with body). Google home sends the rest api call to the local device.
No need to have port forwarding / firewall changes.
The Google Home does very very little on-device processing. Sending out local network calls is not one of the things it does. Almost all processing, including IoT controls through the Smart Home API, are done through cloud-based services.
Update
I can't answer "why" it doesn't do this, since I'm not one of the engineers that built it, but I can make a lot of guesses about why.
For starters - it increases the complexity of the software and hardware on the device dramatically. Right now, the device is really little more than a microphone and a speaker, with a little logic to detect the hotword and then stream everything else to the server, and then get a result back and play it. Most of the rest of the code is likely to handle setup and configuration.
If the device has to also be a general purpose IoT hub, then it needs software and hardware for Bluetooth and possibly other signaling systems. It needs to be able to keep track of the state of other devices on the network and manage that in between power cycles of the device (or even handle interruptions in power for the device itself). Some of the implications of that may need to open up the networking on the device to receive messages, not just send them. It has to have more extensive network configuration - to understand what local networking is and not just what the local router is and how to deal with that configuration (and that configuration when it changes). These are all possible, to be sure, but increase the complexity and, in some cases, lower the security of a device.
And that might be reasonable... if there was significant value in doing so. But you've already stipulated in the question that the voice processing could be done in the cloud, so once commands are sent to the cloud and parsed there - why not also do all of the above (device and state tracking, changing, etc) in the cloud? Particularly since most IoT devices maintain cloud servers anyway because people also want to be able to control or monitor their home devices when they aren't on their home LAN. Having a dual set of commands (some for when you're local, and some when you're not) does make sense in some cases - but also dramatically increases the complexity of both the controller and devices, so most just rely on the cloud, again.
So while I understand why some people would like to have a nice little system that can just sent your play local REST server a command now and then, the reality is that to do this for a consumer system isn't that reasonable.
If you really wanted a system that can do this - you can continue in the hobbyist spirit and build something with the Assistant SDK and your favorite IoT platform.
The “local” API for Google Home is a bit limited. Here’s a doc from someone who reverse-engineered the API.
Looks like they expose Bluetooth and Alarms/Timers, and some limited configuration stuff.
https://rithvikvibhu.github.io/GHLocalApi/
For example let's say someone made an MMO. How would they test that their server can handle the load from iOS gamers? With the Apple's ad hoc distribution program only allowing 100 distributions I don't see how this would be done.
You wouldn't have to drive the load from the actual devices. For load testing, you can create a test harness that drives load on your server (whether it's sockets, http etc...). It just needs to drive load while you monitor performance characteristics (live counters) and find the first bottleneck and fix it. Repeat.
Approach and tools listed here:
http://en.wikipedia.org/wiki/Load_testing
Locked. Comments on this question have been disabled, but it is still accepting new answers and other interactions. Learn more.
Does Apple offer an API or Kit so that I can start my program on the Desktop and transfer files to/from the device (using the desktop program)? The device will have a similar program/sandbox available. I'm trying to avoid requiring the user to run iTunes, DiskAid, or similar program.
I found an earlier answer [1], but it stated to use cocoahttdserver. Shooting from the hip, a http server feels 'wrong' (in the Windows world, I have the Ce Rapi gear [2] to do the same).
Note that I only need to transfer to a single sandbox on the device - not an arbitrary sandbox. If needed, I have both Mac and iPhone developer accounts (for signing, sharing, and other sandbox nicities).
Jeff
[1] iPhone : Transfer of files from Mac/Pc to app
[2] http://msdn.microsoft.com/en-us/library/ms860198.aspx
Sorry, but your options are wireless network transfer or iTunes. Of the wireless network transfers systems, if you need to be able to transfer over the local network HTTP+Bonjour is the best route.
Advertise your service on your desktop computer using a custom service type and use searchForServicesOfType:inDomain: on iOS to match only those services.