Any functionality you want regarding the (concrete) windows, you implement as part of the NativeAppWindow (we can start with Tizen and then move up). So, these windows now have orientation, and locking ability.

Sensor information come to the window, and it will decide whether the orientation of its contents will actually change or not, based on different sources of information: whether it is locked or not, whether the manifest specifies that we need a specific orientation (hypothetical), whether the HTML specifies that we need to lock on a specific orientation (hypothetical).

The extension should hookup with the window code. It should ask the window to lock and unlock, it should observe the window for changes. The window is the main source of the information for the extension. Note that window itself needs information about its own orientation to do its own work.

Creating a "sub-sensor provider" is the wrong way to start here. If the logic of these complicate a lot, we may take things out into a separated object, but still conceptually "under the wings of the window".

PS: window here is NativeAppWindow(Tizen).