Add your firmware to Updater CE.

Start from a base ROM

Base ROMs give custom firmware developers a clean Android foundation with the wireless radio chips enabled. On the Y1 they enable Wi-Fi and GPS alongside the factory Bluetooth and FM; on the Y2 they enable Wi-Fi, GPS, and FM alongside the factory Bluetooth.

These images are the stock Android base (AOSP) with the device wireless radios enabled, so a custom firmware can add network features instead of replacing the radio stack. They are the practical starting point for the publishing steps below.

Use these release asset names

The filename is part of the compatibility signal. Keep the names exact and put the ZIP files in the GitHub release assets, not only in the repository source tree.

How the connection works

Updater CE reads the manifest as its catalogue. Each <package> line tells it the project name, GitHub repository, model, and handler. When a user chooses that project, Updater checks the repository’s GitHub releases and looks for a rom*.zip asset.

Publish a project in five steps

1. Fork the Updater CE repository. Create your own GitHub fork of y1-community/Innioasis-Updater, then clone your fork locally.
2. Prepare a GitHub firmware repository. Make sure the repository is public and its release contains the correct ZIP assets. You can put rom.zip, rom_type_b.zip, and rom_y2.zip on the same release when they belong to the same version.
3. Edit the manifest. Open slidia_manifest.xml in the root of your Updater CE fork. Add one line for Y1 and one line for Y2. The repo value is the GitHub owner/repository; url is the public project page.
4. Test the catalogue. Run Updater from the edited checkout. Select Y1 and confirm the project shows the Y1 assets. Select Y2 and confirm it shows the Y2 release. Check Type A and Type B separately when both are published.
5. Open a pull request. Push the manifest change to your fork and open a pull request against the upstream Updater CE repository. Include the project link, supported models, release tag, asset names, and the devices you tested.

Generate your manifest lines

Paste the URL of your public GitHub repository to create the two <package> lines for slidia_manifest.xml — one for Y1 and one for Y2. The generator reads the owner/repository from the URL, builds the project name from it, checks the latest copy of the manifest so the preview shows exactly where your lines belong, then walks you through opening a pull request with them.

<package name="Your Firmware" repo="your-account/your-firmware" device="Y1" url="https://github.com/your-account/your-firmware" type="img" handler="Custom Firmware" />
<package name="Your Firmware" repo="your-account/your-firmware" device="Y2" url="https://github.com/your-account/your-firmware" type="img" handler="Custom Firmware" />

Submit the lines as a pull request

1. Copy the two lines above. The generator already matched the latest manifest format.
2. Edit slidia_manifest.xml on GitHub. Use the edit link below; GitHub creates a fork and a branch for you automatically.
3. Paste the lines just before </slidia>, keeping the existing entries unchanged.
4. Commit to a new branch (for example add-your-firmware), then open a pull request against the Updater CE repository.
5. In the PR, include the project link, supported models, release tag, asset names, and the devices you tested.

Keep device="Y1" and device="Y2" uppercase, use the exact URL of your public GitHub repository, and keep type="img" and handler="Custom Firmware" for a firmware entry.

Make the GitHub release easy to verify

Give the release a clear tag and release note. The tag is useful to people, but the ZIP asset names are what Updater CE uses to identify the install packages.

Why the model entries matter during flashing

The manifest is not just a download menu. After extraction, Updater CE uses the resolved model to prepare the matching install path. Y1 and Y2 have different platform files, preloaders, scatter configuration, and device layouts.

• Y1: the updater prepares the Y1 path and uses the device’s named partitions when MTKClient is used.
• Y2: the updater prepares the Y2 path and uses the Y2 MT6582 configuration. Full recovery can use physical addresses from the model-correct scatter data.
• Windows and Linux: the available flashing route depends on the platform and the installed tools. Updater CE handles that choice after the model and package are known.
• macOS Y2: the current updater source has a separate manufacturer-tool fallback for this flow. Do not promise a custom cross-platform route unless you have tested it against the current source.

Before you request a merge

1. Validate the XML with an XML parser. A missing quote or closing /> can hide every entry after it.
2. Launch the updater from your checkout so it loads the local manifest before the remote refresh.
3. Check Y1 and Y2 independently. Confirm that the project appears only where its package is supported.
4. Check the release list for rom.zip, rom_type_b.zip, and rom_y2.zip as applicable.
5. Test the actual install on the intended device, with a reliable USB data cable and a recovery plan for returning to Original Software.
6. In the pull request, explain what you tested. Do not describe an untested model as supported.

python -c "from xml.etree import ElementTree as ET; ET.parse('slidia_manifest.xml'); print('manifest ok')"

For a local check, run that command from the repository root. It verifies XML syntax only; it does not prove that a GitHub release contains valid firmware or that a device is safe to flash.

Useful project links