port to Android 2.2 or older (feature req. for the environmentalists)

[ghost]

Haven would be a great way to put old devices to use - devices that just sit in ppls drawers. It's a shame it requires Android 4.1.

We have a bit of social responsibility to fight designed obsolescence and keep electronics out of the landfill.

[fat-tire]

It seems the signal library is requiring api 16 as is simplewave and possibly others. I think the most recent support/appcompat libraries from google would otherwise limit the app to api 14 Android 4.0 (Ice Cream Sandwich).

To go back to api 8(2.2/Froyo) would probably require stripping out a lot of the functionality provided by the more recent libraries and/or finding substitutes. I could see this being useful for phones you can buy for like $20 on ebay or whatever, but maybe it would be a good side-project?

[E3V3A]

@libBletchley Devices sitting in peoples drawers should be re-flashed to whatever the highest available API you can find for it. Making this app downward compatible with APIs that far back, can potentially kill the project due to legacy development overhead. No offense, but its simply stupid to use deprecated APIs for a security and privacy project like this. And I'm not even going to talk about all the other security issues related to this. Also API from KK (4.4) to M(6.0) covers about 93% of the still-in-use market.

[ghost]

@E3V3A

Devices sitting in peoples drawers should be re-flashed to whatever the highest available API you can find for it.

"Available" is the operative word here. Android is (unfortunately) intended to accommodate obsolescence-by-design models. Google used a the flimsy push-over Apache 2.0 license, which enables phone makers to ram-pack the platform with proprietary blobs. Apache 2 frees vendors of the social responsibility of disclosing that code. So we have thousands of phone models that are stuck on old platforms and cannot advance (which likely affects millions of phones).

And when it comes to kernel mods, the kernel is GPLd, but phone makers are simply violating the copyright of Torvalds. That is, they are ignoring requests to for the kernel source. But even if they did comply, the reconstruction of non-kernel black boxes has proven sufficient to kill advancement of the platform for a particular device.

Making this app downward compatible with APIs that far back, can potentially kill the project due to legacy development overhead.

If you've somehow measured that overhead, fair enough. If it's wild speculation, then it's nothing more than something to watch out for.

No offense, but its simply stupid to use deprecated APIs for a security and privacy project like this. And I'm not even going to talk about all the other security issues related to this.

It seems you've fallen victim to the "newer is better" ideology. All versions have security-critical bugs. In information security, we find that new products are rich in bugs of the unknown variety, which puts you at a disadvantage to those running around with 0-days. Bugs in old versions are mostly known, which means we can examine them to decide if we even care, and if there is a known bug we care about we can control for it (which is impossible with unknown bugs).

Can you support your claim with any CVEs that are relevant, and for which we would be unable to control for?

Also API from KK (4.4) to M(6.0) covers about 93% of the still-in-use market.

It's actually the not-in-use market this enhancement is meant to address. As well as the 4.x devices that will soon end up in the not-in-use market, and which may be left behind when Haven decides to advance version requirements more.

[geraldkrug]

4.4 is best