Packaging an app in F-Droid

tl; dr : packaging and shipping a Trojan-free app to control my lamps in F-Droid without any Android development knowledge.



I have a political position, I am a supporter of the FOSS in many ways I agree with Stallman. As is often the case, this position is complemented by mild paranoia. I try to get rid of proprietary applications, especially if they run through third party servers.



And I also have Xiaomi Yeelight "smart" lamps, which are controlled by an application running through the Xiaomi servers. But it has the ability to turn on the API that works inside the LAN in the lamp. To feel at ease, I went looking for the app on Github and Gitlab and now I intend to promote it to F-Droid to support our paranoid community.

Build and check

In order for the application to get into the catalog, it must at least build and, in an amicable way, work. My choice turned out to be meager , and not a single application was found on Gitlab. Of the available applications, I was able to assemble only two, and in the end only one of them started. I am very far from developing for Android, in a few days I mastered only a simple assembly using Gradle, I will describe it further.



We need: git, Java Runtime Environment, Android SDK, Android Debugging Bridge and fresh Gradle. JRE, ADB and git for Debian Testing can be installed from packages apt install git adb openjdk-11-jre-headless.



The Android SDK is usually installed with Android Studio, but I used the sdkmanager console utility :

unzip commandlinetools-linux-6609375_latest.zip
export PATH=$PATH:$PWD/tools/bin/
mkdir android-sdk
export ANDROID_SDK_ROOT=$PWD/android-sdk/

If you thought I missed installing the Android SDK itself, then it didn't seem to you. I'll explain it later. The Debian repositories contain a rotten version of Gradle, the build does not work with it, the fresh one will also have to be installed from the site :

wget https://services.gradle.org/distributions/gradle-6.6.1-bin.zip
unzip gradle-6.6.1-bin.zip
export PATH=$PATH:$PWD/gradle-6.6.1/bin/

I forked the repository to myself and cleaned up the auto-generated garbage. Everything is going like this:

yes | sdkmanager --licenses --sdk_root=$ANDROID_SDK_ROOT
git clone https://github.com/asz/OpenLight.git
cd OpenLight/
gradle wrapper
./gradlew assemble

By the first command we accept in bulk all licensing conditions as required sdkmanagerfor non-interactive installation. When auto-generating the wrapper ( gradle wrapper), Gradle will parse and install all the necessary dependencies. Downloading the required version of the Android SDK, assembly toolkit and other Android-specific dependencies is done with the help sdkmanager, so you don't have to do it by hand, and you will have to accept the license in advance.







It's time to enable the API in the official app. Turn your smartphone debugging of the USB , connect it to your computer and install the generated debug package: adb install app/build/outputs/apk/debug/app-debug.apk. Remember to enable debugging from your computer in the pop-up window on your phone. If the application on the phone shows signs of life, then you can continue.

Preparing a patch in F-Droid

F-Droid has rules for cataloging an app. The basics are pretty simple: no nonfree build dependencies, privacy issues, and any nonfree dependencies of the application itself should be flagged . I didn't check the dependencies myself, because F-Droid has a CI and its own build system, this allows you to simply run the commit through the pipeline.



Now let's go to GitLab, where F-Droid is being developed. First, be sure to check that no one is working on your application yet. Such activity is concentrated in packaging requests and in merge requests . Fork the Data repository and clone it from your profile.



One YML file is enough for the application to appear in F-Droid. Find any suitable YML-file in a subdirectory metadata/of your repository and copy it in the same format applicationId.yml. The value applicationIdfor your application can be obtained from some of build.gradleits own repositories, in my case from app/build.gradle. I don't remember which of the files I took as a reference, I will only show the final file metadata/grmasa.com.open_light.yml: It was difficult for me to choose a specific AntiFeature, but detailed accuracy is not required, indicated . Category suitable for device companion apps. The key describes which commit / tag to build the application from. can also be found in . If you do not want to update the application manually, then you can fill in



AntiFeatures:

- NonFreeDep

Categories:

- Connectivity

License: GPL-2.0-or-later

AuthorWebSite: https://github.com/grmasa

SourceCode: https://github.com/grmasa/Open_light

IssueTracker: https://github.com/grmasa/Open_light/issues

Changelog: https://github.com/grmasa/Open_light/tags



AutoName: Open Light

Summary: Control Xiaomi Yeelight WiFi smart bulbs

Description: |-

Control Xiaomi Yeelight smart bulbs within your Local Area Network.

Only fits WiFi controlled bulbs.



This app requires enabled LAN control for bulbs: open the official app, set up

all the bulbs, go to LAN control in the menu, and enable it for every device.



RepoType: git

Repo: https://github.com/grmasa/Open_light.git



Builds:

- versionName: 1.1.2

versionCode: 1

commit: v1.1.2

subdir: app

gradle:

- yes



AutoUpdateMode: Version v%v

UpdateCheckMode: Tags

CurrentVersion: 1.1.2

CurrentVersionCode: 1



NonFreeDepConnectivityBuildversionCodebuild.gradleUpdateCheckModeand AutoUpdateMode( v%vdescribes the format of the tag).



For basic file checking, you need a utility fdroidfrom the F-Droid Server repository , its dependencies and a variable ANDROID_HOME:

git clone https://gitlab.com/fdroid/fdroidserver.git
export PATH=$PATH:$PWD/fdroidserver
apt -y install python3-git python3-pyasn1 python3-pyasn1-modules python3-yaml python3-requests
export ANDROID_HOME=$ANDROID_SDK_ROOT

You can go back to the directory fdroiddataand check if the metadata is working:

fdroid readmeta
fdroid lint grmasa.com.open_light
fdroid build -v -l grmasa.com.open_light

The first two commands check the syntax, the third builds the application. At the exit you should see the APK: unsigned/grmasa.com.open_light_1.apk.



Just in case, you can run it fdroid checkupdates grmasa.com.open_lightto check for updates and fdroid rewritemeta grmasa.com.open_lightto correctly refill the file with metadata, and then recheck the assembly.

Almost happy ending

Now you can commit and check out the Gitlab CI pipeline. It's all over for me !



I filled out a Merge Request and got it checked and asked to notify the author of the original app. If the author ignores me for more than two weeks, I will simply rewrite the links in the metadata to my fork and then it will be accepted.







Now I can put my special Trojan phone out of the way. And I will even have the opportunity to control them from the Internet in a perverse way, even by banning the LAN with them !



Sadly, there is some truth in the illustration in the title. An unpleasant bug was found in the application at the second stepwizard: from the list of detected lamps, most often not the one I selected is added. Because of this, the lamps are on the main list. To work around this problem, I put the lamps in the application one by one. Hopefully someday I'll figure out what the problem is, or package another application.