Update houdini library with extended expiry date (July 1, 2028) #286

2026-09-06T03:21:55-04:00

SuggonM commented

2026-09-06 03:21:55 -04:00

(Migrated from github.com)

Intel's libhoudini library includes a built-in "expiry date" that prevents execution after a certain date. The previous versions expired on January 1, 2026 (#256) and September 1, 2026 respectively.

This update refreshes the library to a newer build per https://github.com/supremegamers/vendor_intel_proprietary_houdini/issues/6 and has an extended expiry date of July 1, 2028.

Relevant discussion: https://www.reddit.com/r/waydroid/comments/1w4kt8k/libhoudini_stops_working_on_september_1st/

Fixes #285

Intel's libhoudini library includes a built-in "expiry date" that prevents execution after a certain date. The previous versions expired on January 1, 2026 (#256) and September 1, 2026 respectively. This update refreshes the library to a newer build per https://github.com/supremegamers/vendor_intel_proprietary_houdini/issues/6 and has an extended expiry date of July 1, 2028. Relevant discussion: https://www.reddit.com/r/waydroid/comments/1w4kt8k/libhoudini_stops_working_on_september_1st/ Fixes #285

SuggonM commented

2026-09-06 03:33:01 -04:00

(Migrated from github.com)

Fortunately, the support window this time is 2 years. But I'm not entirely certain if this is sustainable in a longer run.

As a concept, binary patching libhoudini.so like this:

def patch_libhoudini(self, path):
    ...
    binary.seek(self.patch_offset)
    binary.write(b"\x90" * 6)
    ...

is a valid option, as we can pinpoint/hardcode the offset and no-op the culprit JUMP instruction, as suggested in https://github.com/waydroid-helper/waydroid-helper/issues/127#issuecomment-5510560514 and https://github.com/waydroid-helper/waydroid-helper/issues/127#issuecomment-5506441807. However, this will require maintaining the offset for both x86 versions lib{,64}/libhoudini.so across possible future libhoudini upgrades.

Another option is to pull from the latest upstream houdini repo without pinning it to a specific commit SHA. This will eliminate the need to make similar commits in the future, while users can simply reinstall libhoudini once the upstream has been notified and updated.

For now, the upstream repo seems semi-active so I followed the tradition of relying on them.

Fortunately, the support window this time is 2 years. But I'm not entirely certain if this is sustainable in a longer run. As a concept, binary patching `libhoudini.so` like this: ```py def patch_libhoudini(self, path): ... binary.seek(self.patch_offset) binary.write(b"\x90" * 6) ... ``` is a valid option, as we can pinpoint/hardcode the offset and no-op the culprit JUMP instruction, as suggested in https://github.com/waydroid-helper/waydroid-helper/issues/127#issuecomment-5510560514 and https://github.com/waydroid-helper/waydroid-helper/issues/127#issuecomment-5506441807. However, this will require maintaining the offset for both x86 versions `lib{,64}/libhoudini.so` across possible future libhoudini upgrades. Another option is to pull from the latest upstream houdini repo without pinning it to a specific commit SHA. This will eliminate the need to make similar commits in the future, while users can simply reinstall libhoudini once the upstream has been notified and updated. For now, the upstream repo seems semi-active so I followed the tradition of relying on them.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wbruno/waydroid_script#286