How To Get Ark Dlcs For Free

0 views

Skip to first unread message

Vickey Melling

unread,

Aug 3, 2024, 3:00:32 PM8/3/24

to riavardwacu

Within the package, must include the src_install function to install the DLC content using a special path prefix set by $(dlc_add_path ). This means, that before installing any DLC files, you have to add the dlc prefix path to into, insinto and exeinto using $(dlc_add_path your_path). Always call dlc_src_install at the end of your src_install function to pack the DLC.

Once your ready to enable your DLC, you can target enabling the DLC package selectively behind your own USE flags or at the top level target-chromium-os package to be enabled across all ChromeOS devices behind the main dlc USE flag.

This warrants always requesting to install the DLC before use at all times. The DLC will remain mounted as long as the device or UI (ash chrome) does not restart. It is completely up to dlcservice to return any type of root mount paths in the future, but the root will always be suffixed at /run/imageloader.

On a locally built test buildimage, calling dlcservice API does not download the DLC (no DLC is being served), unless the DLC is preloaded using Write tests dependent on a DLC. For local development, please follow Building a DLC locally.

In order to test a DLC dependent feature, the optional variable field DLC_PRELOAD needs to be set to true while the integration/tast tests invoke installing the DLC. This will allow tests to seamlessly install the DLC on test images.

There is ongoing effort to tie DLC provisioning into the ChromeOS test run as part of OS provisioning. Also, there are gRPC services that tast/tauto tests can directly invoke to provision a DLC - there however isn't a client that nicely wraps all of this for the test writer at the moment.

Currently, DLCs can be installed without policy checks. This poses a security risk, as code paths or flows that depend on the existence of DLCs could be inadvertently executed or triggered, potentially leading to unexpected behavior or vulnerabilities.

To mitigate this risk, for DLCs that enforce installation behind a policy, we strongly recommend that developers avoid relying on code paths or flows that depend on the existence of DLCs. Ensure that DLCs are only installed when authorized (as needed) and that any code paths or flows that depend on them are executed only under controlled conditions.

If your DLC is a legacy DLC, you must modify your ChromeOS lsb-release to fake being a signed device. This must be done by disabling rootfs verification and adding a -signed suffix to the key CHROMEOS_RELEASE_BOARD.