Skip to content

SomethingOS/manifest

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SomethingOS

Setting up your machine

You must be running a 64-bit Linux distribution and must have installed some packages to build SomethingOS. Google recommends using Ubuntu for this and provides instructions for setting up the system (with Ubuntu-specific commands) on the Android Open Source Project website.

Once you have set up your machine according to the instructions by Google, return here and carry on with the rest of the instructions.

Grabbing the source

Repo is a tool provided by Google that simplifies using Git in the context of the Android source.

Installing Repo

# Make a directory where Repo will be stored and add it to the path
$ mkdir ~/.bin
$ PATH=~/.bin:$PATH

# Download Repo itself
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.bin/repo

# Make Repo executable
$ chmod a+x ~/.bin/repo

Initializing Repo

# Create a directory for the source files
# This can be located anywhere (as long as the fs is case-sensitive)
$ mkdir SomethingOS
$ cd SomethingOS

# Install Repo in the created directory
# Use a real name/email combination, if you intend to submit patches
$ repo init -u https://github.com/SomethingOS/manifest -b uvite

Downloading the source tree

This is what you will run each time you want to pull in upstream changes. Keep in mind that on your first run, it is expected to take a while as it will download all the required Android source files and their change histories.

# Let Repo take care of all the hard work
#
# The -j# option specifies the number of concurrent download threads to run.
# 4 threads is a good number for most internet connections.
# You may need to adjust this value if you have a particularly slow connection.
$ repo sync --current-branch --no-tags -j4

Syncing specific projects

In case you are not interested in syncing all the projects, you can specify what projects you do want to sync. This can help if, for example, you want to make a quick change and quickly push it back for review. You should note that this can sometimes cause issues when building if there is a large change that spans across multiple projects.

# Specify one or more projects by either name or path

# For example, enter SomethingOS/android_frameworks_base or
# frameworks/base to sync the frameworks/base repository

$ repo sync PROJECT

Generating your sign keys

For official, please use the SomethingOS keys

From Android Documentation :

Since the test-keys are publicly known, anybody can sign their own .apk files with the same keys, which may allow them to replace or hijack system apps built into your OS image. For this reason it is critical to sign any publicly released or deployed Android OS image with a special set of release-keys that only you have access to.

Start from your working directory and generate the keys:

mkdir ~/.android-certs
subject='/C=FR/ST=Whatever/L=Somewhere/O=SomethingOS/OU=SomethingOS/CN=SomethingOS/emailAddress=android@somethingos.com'
for x in releasekey platform shared media networkstack; do \
    ./development/tools/make_key ~/.android-certs/$x "$subject"; \
  done

And this will create the signing keys

Building

The bundled builder tool ./rom-build.sh handles all the building steps for the specified device automatically. As the device value, you just feed it with the device codename (for example, 'beryllium' for the Pocophone F1).

-z : Will also generate a fastboot package
-s ~/.android-certs/ : Will use your sign keys

# Go to the root of the source tree...
$ cd WORKSPACE
# ...and run the builder tool.
$ ./rom-build.sh DEVICE -z -s {keys_folder}

Writing good commit messages

You will be asked a commit message when you run git commit. Writing a good commit message is often hard, but it is also essential as these messages will stay around with your changes and will be seen by others when looking back at the project history.

A few general pointers to keep in mind when writing the commit message are that you should use imperative as it matches the style used by the git merge and git revert commands (that means "Fix bug" is preferred over "Fixes bug", "Fixed bug" and others) and that you should write the first line of the commit message as a summary of the commit. It should always be capitalized and followed by an empty line. You might optionally include the project name at the start and try to keep it to 50 characters when possible as it is used in various logs, including "one line" logs.

Code

Our codebase is licensed under Apache License, Version 2.0 unless otherwise specified. Apache License 2.0 allows a variety of actions on the content as long as licensing and copyright notices are retained and included with the code and your changes to the codebase are stated.

You can read the full license text at http://www.apache.org/licenses/LICENSE-2.0

Images & other assets

Unless otherwise specified, all our assets, including but not limited to images, are licensed under Creative Commons Attribution-NonCommercial 4.0 International, or CC BY-NC 4.0 for short. This means that you are allowed to modify the aforementioned assets in any way you want and you are free to share the originals and/or the modified work. However, you are not allowed to use the assets for commercial purposes and you must provide attribution at all times which means you have to include a short note about the license used (CC BY-NC 4.0), the original author/authors (Paranoid Android Project or AOSPA - which SomethingOS is based on) and inform about any changes that have been made. A link to the website should usually be included as well.

You can reach the full legal text at http://creativecommons.org/licenses/by-nc/4.0/

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published