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.
Related
I'm using an app that uses Bluetooth low energy to scan and detect devices however it does not detects other phones
is there a specific way on flutter to make it detect other mobile phones
You can only detect BLE devices that are advertising their services. A mobile phone often does not do that on its own. There are two solutions:
Use an already available app on the other device to advertise some service. One of the possible apps I personally use is nRF Connect, another one would be BLE Peripheral.
This might not be sufficient depending on your project and goal this might not be sufficient. If you need some specific service or characteristic that can't be generated by pre-existing apps you have to develop your own app for advertising. This would be possible with flutter_ble_peripheral (limited functionality on iOS)
I want to write a tracking application, which reacts/record when users get in a car and phone automatically pair with Bluetooth hands free. I need also Id of the hands free device.
On Android it is easy, using Broadcast Receiver your app listen to broadcasts that device had been paired with phone. It is working even after phone had been restarted and App did not run after restart.
Is it possible on iOS(7+) ?
You can do it by reading the "Performing Long-Term Actions in the Background" part of this docs
Essentially, using state restoration, the system takes note of what your app was doing when it was killed.
If the app is searching for a bluetooth device and is killed by the system, the system will take care of continuing this research and wake up the app again when the bt device has ben found.
Note that this will work only if the app is killed by the system, not by the user (using the multitask bar). This behavior has changed since iOS 7.
Alternatively, If your BT hardware can be programmed to send advertisements using the ibeacon protocol, your app can be "awakened" by the corelocation/ibeacon api. After that prompt then maybe the corebluetooth pairing code could be initiated.
I am working on an iPhone and Mac OS X application, which allows you to lock and unlock your Mac via proximity. Means if you the signal strength is under a determined threshold or the connection gets lost it shall lock the mac.
I am working with Apples CoreBluetooth framework for BTLE, using the iPhone as a peripheral and the Mac as a central. So far so good. It also works very well but when I send the app to the background on the iPhone the advertising seems to change. The iPhone still advertises but without the service profile and characteristics, I use in the app.
Although this is not a problem when the iPhone is still in the range of the Mac, because it's still connected and the characteristics are not used in the central, it becomes a problem after moving the iPhone out of the range. As expected the Mac locks and starts discovering to reconnect the iPhone and unlock if succeeded.
But in this discovery, I use the specified service profile and the characteristics to only get devices running my app and to identify the one for unlocking.
I tried a workaround by discovering without a service profile and identifying the correct device via its UUID, which I saved when I started to use this iPhone for locking and unlocking. This workaround also works in a small scope, because when I turn off the Bluetooth on the iPhone and turn it on again, it gets another UUID. That's a constraint I could live with, but it also changes the UUID after a few hours and then the unlocking does not work.
Maybe someone already worked on an app like that and know how to fix such a problem? Or you know a static value which I can use to identify the device?
So it seems, like usual, Apple has some weird and unique things going on in their framework. When you advertise from an iOS device (such as your iPhone), there are two "storage areas" for the advertisements -- a normal one that any device that is scanning can see, and an "overflow" one that can only be seen by iOS devices that are specifically scanning for it. When your app advertises in the background, all services UUIDs that you advertise go into this overflow area unfortunately, so it looks like only other iOS devices can see it -- and not your Mac. From the CBPeripheralManager docs:
Any service universally unique identifiers (UUIDs) contained in the
value of the CBAdvertisementDataServiceUUIDsKey key that do not fit in
the allotted space are added to a special “overflow” area; they can be
discovered only by an iOS device that is explicitly scanning for them.
While your app is in the background, the local name is not advertised
and all service UUIDs are placed in the overflow area.
Im looking to initiate pushcommunication between Android and iPhone, both ways. The data that is to be transferred is critical so therefor I cannot use ordinary push because its not prioritzed.
It is important that the user doesnt "see" the communication.
I have looked at using SMS and "catch" the message before it reaches the ordinary "SMS application" of the phone. As I understand this is possible in Android but not in iPhone.
Any other suggestions?
You can use Bonjour (a.k.a. Zeroconf) for this. There are tons of links for using Bonjour on the iPhone; here's a link for doing it on Android:
http://android.noisepages.com/2010/02/yes-android-can-do-zeroconfbonjour-jmdns/
Is it possible to communicate two instances of an app:
In nearby devices (Android or iPhone)
Without user intervention (aside from starting the app once)
Without internet (but not network) connection?
How?
Android to Android?
iPhone to iPhone?
Android to iPhone and vice-versa?
Let us ignore the issues associated with implementing the network communication at the application level and focus on the system design problem your question raises.
You want an application on one device to connect to another associated application on another device without any user intervention/interaction beyond launching the device. In order for this to work your system is going to need a 3rd party separate from the two devices/applications that provides a lookup service.
What will need to happen is each application will need to communicate with this service, ask for the data regarding other device it should connect to, if it exists, and then attempt that connection. This is basically how a bittorrent tracker works.
Keep in mind that there's quite a bit more involved in the implementation than that simple scenario suggests. For example, the proper registering/unregistering of devices, registration timeouts, security, etc.
Unless I misunderstand your question, you should be able to just use standard sockets (TCP or UDP depending on your needs) for communication between any/all devices. For iPhone, you could probably use the NSStream classes and for Android you'd use the Socket classes.
Can the new NFC feature be an answer to this?