LightNetwork device battery level

Ah, I'll probably leave the radar support out if I ever release it and just provide a download link for the full version

When you submit an app to the store, there's this question:

They don't decompile,  but do expect that you answer this correctly.

And there's no way for an app to see the serial number of the device it's running on,

OK. I just though about System::DeviceSettings.uniqueIdentifier or checking if the AntPlus::ProductInfo.serial would give something for a particular device. Well, sideloading it is...

uniqueIdentifier isn't specific to the device (like  serial number would be), but is unique to an app on a device. (it's different based on app)

jim_m_58 said:

They don't decompile,  but do expect that you answer this correctly.

We have ways.

So would it be OK to have an app that e.g. uses the rear radar but the feature would only be activated in a non-documented way? And a follow-up question, what could that way be? If the serial of the device (or a connected ANT+ device) can't be read, how about the presence of a local file or a "Open, Sesame" message sent to a connected phone?

First off, I'm not convinced that we'd remove your app just because it used the light network. If we were going to prevent published apps from using these features at all, then we wouldn't have added the functionality to the API, or we'd have added it in a way that would prevent external developers from using it.

If you are concerned about doing a bunch of work and having the app pulled after you put a bunch of work into it, I can put you into contact with the right people so we can try to firm up the guidelines for what constitutes an app designed for safety awareness purposes.

There are ways that you can unlock functionality in an app. As jim_m_58 suggested, you could check the uniqueIdentifier value against a whitelist. You could use the app unlock functionality, but II think that is only available to partners (we have to work with you to get that running). You could also use some sort of web authentication system, or you could use the app settings (you enter a 'key' into the app settings or in a menu, and if it matches a known key the feature would unlock).

That said, I think you should have a conversation with the appropriate persons to determine what the rules are. By having that conversation, you're hopefully encouraging us to determine exactly what criteria we are using to decide whether such an app would get rejected/removed. Once we have that criteria, we should update the documentation. The current policy seems like  Additionally, if you are told that you can't make the app that you want, you can also find out if we would pull your app for using a 'super secret' unlock method described above.

Thanks for your response. I'll see what the app shapes up to be. One would think that use of the e.g. the Varia back radar could be considered "designed for safety awareness purposes" if it doesn't work properly.

Nik said:

One would think that use of the e.g. the Varia back radar could be considered "designed for safety awareness purposes"

I think providing a data field/widget that shows Varia battery status would not fit that description. I *think* we want people to not reproduce the functionality for threat identification/notification that we build into the devices, but again I didn't make up the rules.

Right now our guidelines are basically the same as Potter Stewart's definition of obscenity. We can do better.