According to the Android Wear 2.0 guide, Android Wear 2 apps will be installed separately, one from the Play Store on the phone and one from the Play Store on the watch, unlike Android Wear 1.x apps which are packaged together
So guidelines suggest that app should notify user if companion application is required, but not installed on the connected device.
However, not all watches will get 2.0 upgrade and some will stay at 1.x. Those watches install apps companion automatically and if one is missing, it just means app takes a while to install through Bluetooth connection. Displaying "install companion app" notification would be meaningless on these watches as there is nothing user can do to speed up the process (there is on Play Store on older watches).
Now, the issue is that I can't find a way to display warning if connected 2.x watch does not have the app and at the same time not displaying the warning if connected watch is running 1.x.
Is there a good way to distinguish between the two different connected Android Wear versions?
There's not a good way to do this right now. It's been discussed a couple of times on the Wear developers G+ community, and the best we came up with is:
Go ahead and send the RemoteIntent to open the Play store.
Attach a RemoteIntent.ResultReceiver when you do so.
If the watch is running Wear 1.x, this will return with a resultCode of RESULT_FAILED, and you can show your user a message accordingly.
This is obviously not ideal; it involves a useless step (trying to open the Play store) for 1.x users, and there's also no way to distinguish any other possible failure modes. But as of today, it's the best we have.
Discussions:
https://plus.google.com/+SterlingUdell/posts/XJZ8mAsaZ8B
https://plus.google.com/u/0/+SterlingUdell/posts/WWBVxjcD7vT
Related
My goal is to write an application for Android (>= 9.0) which basically offers a device-owner-style control like Google's "Android Device Policy".
The following criteria have to be met:
Zero dependency on Google servers or any other 3rd party infrastructure like existing EMM solutions (MobileIron et cetera)
The user should not be able to remove or disable the app
Provisioning methods: QR-Code, NFC, URL, ADB, actually any "local" way ...
Has to work with stock androids on regular consumer devices
In short: I'd like to write an unremovable device manager (including a web-based management UI), put it on a device I own, give that device to someone else, and being able to fully control the device remotely.
Is such a project even possible with the current situation of Android?
No.
Has to work with stock androids on regular consumer devices
Mostly, this is your biggest hurdle to overcome.
What you are asking for is the description of a very powerful MalWare. An app that ca run on any version of Android, that can't be uninstalled, but can do what it wants to "fully control the device".
If you move away from the idea of "stock android on regular consumer device", towards a suite of devices you have some say in distributing:
Here is a list of Google Partners who offer an EMM solution: https://androidenterprisepartners.withgoogle.com/emm/
Here is Samsungs effort at device control:
https://www.samsungknox.com/en
Here is Googles device management:
https://developers.google.com/android/management
You could write your own ROM of Android and be able to control the things you want, but that would require .. building a ROM aka a whole phone OS forked from AOSP.
The user should not be able to remove or disable the app
This is only possible if you have a system app.
Or something extreme (which with any extreme, is always possible to have problems), like having two apps, and they monitor each other for uninstall, and programatically reinstall (vs 1 app that can't do much when it is being uninstalled).
maybe someone know , samsung have a powerfull core with name KNOX SDK.We have application which based on this sdk. And we are looking a way to do same application without knox sdk. But we stuck with simple function like kiosk mode. This mode not working if device owner is not setted for application (for me it's hard to understand) All what i found - it's this way :
This way is correct if im testing application myself. But when time is come and we will need to install this application on our 100-200 devices , then this way looks bad . Every device to do factory reset, and adb commands etc.
So question :
I'm sure there are should be a way to do this offically. But i can't find any info about this. Maybe some one know how to do this ? Please help. I'm sure i'm missed something somewhere. :)
You can get information about the ways to provision device here. They include:
QR code
Managed Google Play Accounts
Google Account
NFC
I've wrote an article where I've described provisioning with QR-code here. We've selected this way for our Kiosk application as the most optimal one, because:
zero touch enrolment works only on a small subset of devices;
NFC provisioning requires another device with special app;
Google Account requires having and managing this account.
On the other hand QR-code works almost on all Android 7.0+ devices ("almost" because some vendors disable this in their custom ROMs) and is easy to setup for end user.
But when you need to install it on multiple devices (and it's some internal app, so you do it yourself, rather than end user) Google Account can be more appropriate.
In production, you'll want to provision your dedicated devices from the factory reset state (on the initial blue screen) using NFC, a QR code, or if supported, zero touch enrollment. NFC can be used from another Android device using an app such as the NFC provisioning app. A dedicated NFC card can also be programmed using an app such as NFC Tools. Google provides provisioning instruction on their TestDPC github repo. EMMs will also provide instructions for their DPC app. Using Android Management is usually a better alternative to TestDPC for production deployments under a 1000 devices. Additonal provisioning options and increased API usage limits are available if you're part of the EMM Community.
I want to publish android wear2.0(standalone) apk to the playstore.My phone app is already published on the playstore with wear1.0.4 embedded apk.
Right now I am running wear2.0 apk on emulator for testing.
But I have no clue how to sync it with my android phone(without using bluetooth) or an iphone.
Please guide me.
The same way as Wear 1.0. The way I've been publishing the phone app and the wear app is that my wear app's version code is one higher than the phone app but since it differentiates by feature (watch), both are on the Play store simultaneously. The embedded apk for wear 1.0 goes to the watch with the phone app but wear 2.0 watches show a notification for the user to download your (wear 2.0) app from the watch play store.
As long as the package names are the same, you can sync data using the Data APIs. Less recommended but since the watch has Internet now, you can even sync in other ways.
I am planning a new application that I would like to put on the smartwatch. I would like to have it usable also when there is no phone nearby. The app needs no Internet connection to work, could synchronize data to the phone later and I do not need anything from the phone while the app is running. However I could use the phone no problem to install the app.
I have googled, there are some foggy talks on a web that this is not possible, Android watch must always be connected to the phone for apps to run. How much is it true?
With Android Wear 2.0 it is possible to now develop standalone applications and thus eliminates the need for a mobile 'companion' completely.
Please follow this link for more information: https://developer.android.com/wear/preview/index.html
As I am aware, the current Android Wear version always requires a companion app for installation purposes etc. But with 2.0 this is no longer necessary. It would probably make sense for you to start developing with 2.0 now. That being said, it is still in a development preview and can officially run on only two smart watches (Huawei Watch and LG Watch Urbane 2nd Edition)
Wearable apps are run directly on wearables and don't require presence of a phone except for installation or phone-provided features (voice recognition, SMS, internet connection etc.)
Note that some features are wearable-provided or phone-provided depending on the hardware configuration of the watch/wearable (eg. GPS).
Yes, it is most definitely possible. As long as the wearable app doesn't require any functionality from the phone then it can operate as a standalone device. It will require a companion app on the phone to install the app on the wear device.
There are several wear apps that work without the need to be tethered to the phone, including Google Play music. There is the possibility of designing wear apps for hardware on only a few wear devices - I know that Ghostracer has standalone functionality using GPS, but it requires the wear device to have a GPS chip (it is designed for the Sony SmartWatch 3).
A question on limiting apps for devices. We've licensed software to device makers and we wanted to allow app developers to publish only on those devices (I'll call these "licensed devices"). Apps won't work on other devices("non-licensed devices").
I've found very helpful posts here about Device Availability & Google Play.
Android: Limit supported devices in Android Market
how to filter android app to be downloaded from google play to specific device? among others
With Device Availability, it looks like app developers have to manually select the universe of non-licensed devices from the dynamic list of supported devices and move these to the exclusion list. Seems like a lot of work for app developers, especially if they'd have to keep updating the exclusion list with each new Android device that's released.
I wanted to see if there's a means of doing the converse - making my app available only to a set of licensed devices. Is there a means of doing this with Google Play?
We've licensed software to device makers and we wanted to allow app developers to publish only on those devices (I'll call these "licensed devices"). Apps won't work on other devices("non-licensed devices").
Developers of such custom firmware extensions should do so as an SDK add-on, thereby requiring developers who use those extensions to have a corresponding <uses-library> element in their manifest. The Play Store should then automatically filter the app so that it only shows up on devices that have that SDK add-on. Motorola, HTC, Samsung, and others have created such SDK add-ons.
I wanted to see if there's a means of doing the converse - making my app available only to a set of licensed devices. Is there a means of doing this with Google Play?
No, sorry.
Tomorrow, if Google adds one more device to the list of supported devices then it will be automatically included to my supported devices list which I dont want to happen.
Then do not distribute the app on the Play Store.
Is there a mechanism to get a notification as soon as Google adds a new device to the list of supported devices in Google play console?
No, sorry.
If not, what is the alternate way of handling it.
Refresh your browser continuously, breathlessly waiting for the next update to the device roster.
I am sure many other android developers would have faced the same issue
Hopefully not. The Play Store is designed for distribution to all Android devices. The per-device exclusion list is designed for short-term compatibility issues, while you work out some bug fixes to overcome the issues.
It seems like Google has just released Google Play Private Channel, which could help you with your "licensed device" issue.
As said recently in this blog post: A new way to distribute your internal Android apps
Not natively. You can check the device type and exit if it doesn't match your whitelist, but that can easily be spoofed on rooted devices. If you have a library you can throw a fatal exception when initializing, etc.