API Levels in OH SDK

Development Add-ons
#1

I wish there is api level support from OH 3.0 onwards.

http://www.dre.vanderbilt.edu/~schmidt/android/android-4.0/out/target/common/docs/doc-comment-check/guide/appendix/api-levels.html

Some text from above link, copy pasting here.

Updates to the framework API are designed so that the new API remains compatible with earlier versions of the API. That is, most changes in the API are additive and introduce new or replacement functionality. As parts of the API are upgraded, the older replaced parts are deprecated but are not removed, so that existing applications can still use them. In a very small number of cases, parts of the API may be modified or removed, although typically such changes are only needed to ensure API robustness and application or system security. All other API parts from earlier revisions are carried forward without modification.

The framework API that an Android platform delivers is specified using an integer identifier called “API Level”. Each Android platform version supports exactly one API Level, although support is implicit for all earlier API Levels (down to API Level 1). The initial release of the Android platform provided API Level 1 and subsequent releases have incremented the API Level.

Application forward compatibility

Android applications are generally forward-compatible with new versions of the Android platform.

Because almost all changes to the framework API are additive, an Android application developed using any given version of the API (as specified by its API Level) is forward-compatible with later versions of the Android platform and higher API levels. The application should be able to run on all later versions of the Android platform, except in isolated cases where the application uses a part of the API that is later removed for some reason.

Forward compatibility is important because many Android-powered devices receive over-the-air (OTA) system updates. The user may install your application and use it successfully, then later receive an OTA update to a new version of the Android platform. Once the update is installed, your application will run in a new run-time version of the environment, but one that has the API and system capabilities that your application depends on.

In some cases, changes below the API, such those in the underlying system itself, may affect your application when it is run in the new environment. For that reason it’s important for you, as the application developer, to understand how the application will look and behave in each system environment. To help you test your application on various versions of the Android platform, the Android SDK includes multiple platforms that you can download. Each platform includes a compatible system image that you can run in an AVD, to test your application.

Application backward compatibility

Android applications are not necessarily backward compatible with versions of the Android platform older than the version against which they were compiled.

Each new version of the Android platform can include new framework APIs, such as those that give applications access to new platform capabilities or replace existing API parts. The new APIs are accessible to applications when running on the new platform and, as mentioned above, also when running on later versions of the platform, as specified by API Level. Conversely, because earlier versions of the platform do not include the new APIs, applications that use the new APIs are unable to run on those platforms.

Although it’s unlikely that an Android-powered device would be downgraded to a previous version of the platform, it’s important to realize that there are likely to be many devices in the field that run earlier versions of the platform. Even among devices that receive OTA updates, some might lag and might not receive an update for a significant amount of time.

#2

No need to copy/paste. Every developer here knows about semantic versioning (which is even better than googles API level).

There are many discussions about this already and at the moment nobody has time to introduce semantic versioning for the 30+ bundles that the core consists of.

#3

So basically we are saying there is no plan to introduce forward compatibility, either way.

A jar/kar working with 3.0 won’t necessarily work with 3.1. Basically you are saying the APIs are not binary stable for more than 6 months. You must recompile or refactor, which means you must have source code of the said component. That means binary commercial addons are not endorsed by the OH project.

#4

How could binary commercial addons be endorsed by an opensource project ??? :roll_eyes:

#5

Because they can enrich user experience, provide some hw integration which involves patents/security/military/non dosclosure agreements. More users leads to more traction to open source project. There is benefit to everyone, the OH community, user, developer/company.

The more the code written against a platform, the more its value. Tomorrow you may charge what Oracle charges for their JVM, $10 per year per RaspPi like device. The jar that uses JDK 1.2 still works on JDK 1.8.

#6

I think you reverse the problem. It’s the commercial part, that benefits from the opensource platform, so they’ve got to deal with their constraints, and assume the work of relaying on an opensource platform to make their business. Contributors only do this for their own purpose, and the pleasure to be part of a bigger project. But in fact, I do not see the point. OH is how it is… like it, help enhance it, or leave it to others and find a platform that does better serve your goals.

And its quite difficult to compare JEE platform to OH platform in term of contributors, as well as in term of users. The developper base is quite small, so can not afford having a too long technical debt (OH1 compatibility layer being a good example). At one time, decisions must be taken if we want to keep on moving.

2 Likes
#7

Yeah that worked great. Not. Actually all big players turned away from Java because of Oracles policies. Android and Amazon was the biggest Java consumer that I know of (in terms of developers using it). Android moves to a different language and Amazon uses openJDK now.

By the way, you did not read about openHABs history did you? Otherwise you would have known that openHAB 1 turned into Eclipse Smarthome (binary stable guarantee) and now is reintegrated into openHAB core again, because it was too expensive to keep Eclipse Smarthome alive. Surprise.

#8

There is a reason, Linux as a desktop os has 5% market share, and Android which is based on Linux core, has over 70% of market share by volume.
Linux is purely run from open source spirit. There are very few commercial apps for Linux. While Android takes care of providing commercial developers / companies with a solid SDK, and platform API stability.

OH wants to head in Linux direction or Android, remains to be seen.

#9

The difference is that they all give you Android to sell something, while Ubuntu never got one pence from me, as I do not expect any from the users of my bindings - if there are some-. This discussion is pointless

1 Like
#10

Do you use Ubuntu on your phone? I am guessing not.
95% of PC users neither.

#11

I found a troll.

4 Likes
#12

Ok let’s stay on topic. Whatever the reason is Linux or Android is or isn’t successful I don’t think is purely related to the api strategy.

You started with asking for supporting multi api strategy. So let’s discuss the feasibility of that. Even if we decide this is the way to go and promote it. At the end of the day someone has to program it.
So if there be a commercial company or if someone wants pay for it. It’s simple that company can simply start building it and contribute it. However I don’t see any indication that is happening.
The other option I see is an individual developer who wants to implement such a thing, and I honestly don’t see a reason what that will bring for that developer, which is mostly the drive to contribute something. So I don’t expect that to be a realistic scenario.

So unless someone or some company is going to make a large investment (like with Android) I don’t see this happening. Even if we wanted…

#13

What if money and developers come in for this feature? Do we have consensus on key architectural things? If yes, please point me to such a consensus. Or let there be brainstorming, on strategy and technology at least.

#14

Or let there be some kotlin…

1 Like
#15

yeah, me too!

#16

Key architectural designs start as an issue on GitHub. This was on Eclipse smarthome and now on openHAB-core. There are several examples on there. For example here is a recent one on the ui: https://github.com/openhab/openhab-webui/issues/24. It starts with a proposal, which is than discussed. In general this proposal is made by a person or company that is actually going to implement the feature. This is very feature driven and that is purely practical because as mentioned before setting global strategies without actual implementation resources backing doesn’t work, because if nobody is going to implement it, it will never be realised. Basically if you build you can lead.

1 Like
#17

That sounds fair. Because tomorrow if I throw in a million dollars and 5 devs full time on certain things, I wouldn’t be happy if there is vetoing at last minute, even if there were discussions and consensus already. Forking the movement or staying closed source, would be the options to any such investor/contributor.