Replace unmaintained android-properties crate with ndk API

[MarijnS95]

I was surprised to find the android-properties crate with almost 8 million downloads; this crate hasn't been updated for almost 5 years and the repository is a public archive.

Turns out the only published user of this crate is android-activity, so all those downloads are pulled in from folks using this crate (mainly through winit) to build Android apps.

Instead of using an unmaintained, archived crate, use the properties wrapper and typed API-level wrappers provided in in an upcoming ndk crate release instead:

• Add bindings for querying and setting Android System Properties ndk#495
• ndk: Add definitions and bindings for API levels ndk#479

[rib]

I wonder if there's a way to use ndk_sys if that means the change doesn't require a semver bump and can be backported to 0.6. (though I don't quite recall if ndk_sys types are exposed in the public api for android-activity to know if we can bump the ndk_sys dep on 0.6)

Or, maybe the API is trivial enough to just inline the ffi bindings in android-activity if we want to avoid the external dep without needing any other dep bumps.

[MarijnS95]

By that logic I might as well stop maintaining the ndk and ndk_sys crates, if every project open-codes the bindings and abstractions.

[rib]

By that logic I might as well stop maintaining the ndk and ndk_sys crates, if every project open-codes the bindings and abstractions.

not really - it's questionable whether these bionic __system_ functions are ndk APIs for one (similar to how __android_log APIs aren't currently considered to be part of the ndk API).

although the crate is unmaintained it did also kind of make sense that there was a crate that provided orthogonal bindings for just those APIs - similar to how we have android-logger or paranoid-android for logging.

if android-activity is apparently the only crate that depends on android-properties then it could potentially be reasonable to copy the minimal binding into android-activity (one benefit being that we don't have to care about any public api abstraction).

I was also throwing the question out from the pov of having an easy solution that also works for 0.6

are you maybe expecting to add these property api bindings to a ndk 0.9.x release? if so then there will be no issue with being able to use them from android-activity without having to worry about a semver breaking change from bumping the ndk version.