# Getting Started

# Introduction

First of all, you will need basic scripting knowledge in bash. Not only that, if you have experience with python then you also make the good use of it.

There are two kinds of package which you can use.

  • Prebuild Kernel Package
  • Prebuild Mesa Package
  • Custom Core Package

Note: It doesn't matter what package you use, prebuild-kernel package is here to make it easier on making kernel packages quickly. There isn't any functional change between custom-core & prebuild-kernel package.

Protip: If you want to build a Mesa/Kernel package easily, then the best way is to use the on-device GearLock GDK. (Means there is a option to AutoMake Kernel/Mesa Package from your booted kernel/mesa in GearLock >> More >> Dev-Zone on an android-x86 OS with GearLock installed)

# Setup build environment

There are two ways in which you can work with gearlock packages.

  • From an android-x86 system with GearLock installed.
  • Using the linux dev-kit for GearLock

# + From an android-x86 system with GearLock installed


Either open GearLock App or run gearlock in Alt + F1 terminal.

Then go to >> More >> Dev-Zone and you should have all the extended dev-kit options.

Use option 1 to setup build environment

# + Using the linux dev-kit for GearLock


Clone the repo from github

git clone https://github.com/AXIM0S/gearlock-dev-kit

Execute ./configure to setup build environment

To build your package/extension, execute ./build

# Custom-core package

Structure of custom-core package:

.
|-- !zygote.sh      <-- Package functions and information (sourced by gearlock)
|
|-- data               <-- Placeholder data folder
|
|-- gearlock           <-- The gearlock folder
|   |
|   |-- dependencies   <-- Common depdir ($GHOME/dependencies)
|   |
|   |-- extension.sh   <-- Extension script for GearLock interface
|   |
|   |-- gearboot
|       |
|       |-- boot-comp.sh
|       |
|       |-- post-boot.sh
|       |
|       |-- post-fs-data.sh
|       |
|       |-- post-fs.sh
|
|-- install.sh      <-- Initial script which is executed after package extraction
|
|-- readme.txt      <-- Local readme file for the custom-core package
|
|-- system             <-- Placeholder system folder
|
|-- uninstall.sh    <-- An Empty uninstallation script

5 directories, 9 files (structure generated by `tree')

# Pre-build kernel package

The pre-build kernel package has everything ready for you.
You have to just place your corresponding kernel files.

Structure of pre-build kernel package:

.
|-- !zygote.sh      <-- Package functions and information (sourced by gearlock)
|
|-- install.sh      <-- A ready to use univarsal kernel installation script
|
|-- kernel          <-- Placeholder kernel-zimage (replace with your kernel-zimage)
|
|-- readme.txt      <-- Local readme file for the prebuild-kernel package
|
|-- system             <-- The system folder
|
|   |-- lib            <-- The lib folder
|       |
|       |-- firmware   <-- You can include additional firmware (optional)
|       |
|       |-- modules    <-- This is where you put the kernel module folder
|             
|-- uninstall.sh    <-- A pre-configured uninstallation script for kernel packages

3 directories, 5 files (structure generated by `tree')

# !zygote.sh configuration

!zygote.sh is the file which holds your package/extension information and defines how it will act upon installation through GearLock. You can either manually modify it or dev-kit will ask during build.

#######################################################################################################
#####=============================== Package/Extension Information ===============================#####

NAME="Something_Cool" #Package/Extension Name

TYPE="Package" #Specify (Package / Extension)

AUTHOR="AXON" #Your name as the Developer/Owner/Packer

VERSION="v1.0" #Specify the Version of this package/extension

SHORTDESC="Bakes you a cake @_@" #Provide a short description about this package/extension

C_EXTNAME="" #For Specifing a custom name for your extension script ($NAME is used if not defined)

#####=============================== Package/Extension Information ===============================#####
#######################################################################################################


#######################################################################################################
######=============================== Package/Extension Functions ===============================######

REQSYNC="yes" #Require Sync (Deafult - yes)

REQREBOOT="no" #(Deafult - no) Use if your package/extension modifies any major system file

GEN_UNINS="yes" #(Deafult - yes) If you want GearLock to generate a uninstallation script itself

SHOW_PROG="yes" #(Default - yes) Whether to show extraction progress while loading the pkg/extension

DEF_HEADER="yes" #(Default -yes) Whether to use the default header which print's the info during zygote

######=============================== Package/Extension Functions ===============================######
#######################################################################################################

Note: All the variables in !zygote.sh are accessible within anything inside your package during installation.

# install.sh / uninstall.sh exit code

Even if you do exit on your install.sh GearLock will attempt to run the additional jobs such as generating uninstallation script, checking for reboot request and so on. Because GearLock doesn't know whether you're assuming the operation successful or not. So, to tell GearLock that there has been an error and it shouldn't proceed further with the additional jobs then you can return special code which GearLock can read.

You can acheive this in the following way:

exit 101

For uninstall.sh you have to use return 101 instead of exit 101 since gearlock will convert it into a function.

# Extension script/executable

If you want to push a script/executable which can operate whithin gearlock for users then you should do it on ./gearlock/extension.sh

Once someone install your package/extension, they will be able to execute the extension through GearLock > Extensions

Note: You don't have to manually copy or remove extension.sh, GearLock will take care of that.

If you're using custom-core package and if you don't want to make an extension then you must delete ./gearlock/extension.sh

Protip: For live-testing how a extension works, put any executable on $GHOME/extensions
Then do GearLock > Extensions

# GearBoot Executables

GearBoot executables are executed during boot.
Note: You don't have to manually copy or remove gearboot executables, GearLock will take care of that. Check custom-core package structure and GearBoot page.

# Uninstallation modes

GearLock Package Manager deals with package/extension uninstallation system with much effiency.
Which also includes auto uninstallation script generation.

There are three uninstallation modes.

  • With GEN_UNINS=yes in !zygote.sh & custom code in uninstall.sh

Merges generated uninstallation script and from uninstall.sh

  • With only GEN_UNINS=yes in !zygote.sh & uninstall.sh removed

Only merge generated uninstallation script

  • With only uninstall.sh and GEN_UNINS=no

Only merge uninstall.sh

Note: If you don't script any custom uninstallation code in uninstall.sh then you can either remove that file or just leave it as-is. Also, You don't have to manually copy or deal with uninstall.sh, GearLock will take care of putting it in the right place and removing it when necessary


When GEN_UNINS is set to yes, GearLock will generate an uninstallation script based on the files that you put on either system or data folder. You can also mix up/use GEN_UNINS and your custom uninstall.sh together.