Hey everyone, I have a Samsung galaxy s5 running Lineage 16, for sometimes now there's something really strange happens to my phone everytime I turn on the wifi hotspot, and left it for an hour and come back, the phone shows more than 10 device connections been made, and I have change my password and id and still the connections will always connected by 10-20 devices. However, sometimes the USB port does not get turned back on when it is needed or is inadvertently turned off. For USB devices such as the FLEX-1500 and the FlexControl, powering down the USB port causes the devices to disconnect and possibly not reconnect properly, resulting in errors or an inoperable device.

1. Lineage Power Port Devices Drivers
2. Lineage Power Port Devices Driver Windows 7
3. Lineage Power Port Devices Driver Updater

Here’s my build of LineageOS 17.1 for Raspberry Pi 3 Model B and Model B+. It is unofficial and unsupported by the LineageOS team. It’s for advanced users only.

Important! This image includes parts that are licensed under non-commercial license (Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International). You may use this build freely in personal/educational/etc use. Commercial use is not allowed with this build!

Do not mirror my builds! Please post a link to this page instead.

lineage-17.1-20201108-UNOFFICIAL-KonstaKANG-rpi3.zip
https://www.androidfilehost.com/?fid=10763459528675579938
md5:2f0d503a5bbea5a4e15fbec22d767aff

Working:

• Audio (HDMI, 3.5mm jack, USB microphones, bluetooth speakers/headsets, etc)
• Audio DAC (using PCM512x DACs e.g. Hifiberry DAC+)
• Bluetooth
• Camera (using official Pi camera modules & UVC USB webcams)
• GPIO
• GPS (using external USB modules e.g. U-Blox 7)
• Ethernet
• Hardware accelerated graphics (VC4)
• HDMI display
• I2C
• IR remotes (using external GPIO IR modules e.g. TSOP4838)
• RTC (using external GPIO I2C modules e.g. DS3231)
• Serial console (using external GPIO serial console adapters e.g. PL2303)
• SPI
• Touchscreen/multi-touch (USB touchscreens, Waveshare SPI touchscreens, official 7” touchscreen using SwiftShader software renderer)
• USB (mouse, keyboard, storage, etc)
• Wifi
• Wifi tethering

Not working:

• Hardware video decoding & encoding (software decoding & encoding works)

Issues:

• SELinux is in permissive mode
• and more…

Sources:

Thanks:

• Peter Yoon and everyone who has contributed to android-rpi
• brobwind for graphics and bluetooth fixes
• Eric Anholt for VC4 graphics driver
• Google for Android Things platform
• Android-x86 project
• LineageOS team & everyone who has contributed to LineageOS 17.1

How to install:

1. Follow the official Raspberry Pi instructions for writing the image to the SD card (Linux, Mac, Windows).

FAQ:

Q: How to enable developer options?
A: Settings -> About tablet -> Click ‘Build number’ several times. You need to ‘drag’ the settings menu to reach the ‘About tablet’ section that is last on the list.

Q: How to enable root access?
A: You can enable root access under Settings -> System -> Developer options -> Root access. LineageOS no longer has built-in root management for applications. You should keep this option disabled at all times when you are not using an app that explicitly requires root access.

Q: How to enable local terminal application?
A: Settings -> System -> Developer options -> Local terminal

Q: How to enable advanced reboot options?
A: Settings -> System -> Developer options -> Advanced restart

Q: How to find several Raspberry Pi specific settings options?
A: Settings -> System -> Advanced settings

Q: My display is not working. I can only see the rainbow screen but no Android boot animation. What should I do?
A: This build only supports HDMI displays that report supported resolutions using EDID. See this page under ‘Which values are valid for my monitor?’ to see how to check in Raspberry Pi OS which resolutions your display supports. 1280x720 resolution is used by default with this build. You can try changing value in /boot/resolution.txt to use a different resolution that your display supports. Removing /boot/resolution.txt will try to use the preferred resolution for your display.

Q: Settings -> Storage shows total system size of 7 GB. There’s unallocated space on my sdcard. What should I do?
A: This is a 7 GB image, remaining space on your sdcard will remain unallocated. Easiest way to extend /data partition is to simply flash my resize zip in TWRP.

Alternative option is to use e.g. GParted and extend /data partition (/dev/block/mmcblk0p4) to cover the unallocated space. Resizing the partition manually will break support for encrypting /data. Format /data in TWRP recovery (Wipe -> Format data) after resizing to leave required space for crypto footer.

Q: I have official 7” LCD display and touchscreen. What should I do?
A: Official 7” touchscreen is only supported using SwiftShader software renderer. See below how to switch between different graphics drivers. You will also need to change display size under Settings -> Display -> Display size (or change ro.sf.lcd_density to 120 in /vendor/build.prop) to adapt to the smaller resolution.

Q: I need to use SwiftShader software renderer to use the official 7” display or I want to boot without any display connected. What should I do?
A: Warning, SwiftShader is a software renderer and using it affects graphics performance. You can switch between MESA and SwiftShader graphics drivers using a settings option found in Settings -> System -> Advanced settings -> Graphics drivers.

Also the previous method of executing following commands in ‘adb shell’/serial console/terminal still works:

Q: Raspberry Pi doesn’t have a power button. How to power off/reboot device?
A: Following keyboard keys work as Android buttons: F1 = Home, F2 = Back, F3 = Multi-tasking, F4 = Menu, F5 = Power, F11 = Volume down, and F12 = Volume up. You can also use one of many third party reboot applications.

Q: How to create a DIY hardware power button?
A: You can send power button events by connecting GPIO21 to ground.

You can enable the feature by using a settings option found in Settings -> System -> Advanced settings -> Power button.

Also the previous method of executing following commands in ‘adb shell’/serial console/terminal still works:

You can also use the DIY power button to boot the device to TWRP recovery. Press and hold the button while powering on the device until you see the TWRP screen.

Q: How to enable audio through 3.5mm jack?
A: You can enable the feature by using a settings option found in Settings -> System -> Advanced settings -> Audio device.

Also the previous method of executing following commands in ‘adb shell’/serial console/terminal still works:

Q: How to use IR remote?
A: You can enable the feature by using a settings option found in Settings -> System -> Advanced settings -> Infrared remote.

You can place a keymap for your remote as /boot/rc_keymap to be automatically loaded on boot (see available keymaps for reference).

Q: How to use RTC?
A: You can enable the feature by using a settings option found in Settings -> System -> Advanced settings -> Real time clock.

System time is automatically read and set from the RTC on boot once you’ve enabled the feature. You need to write the system time you want to use to the RTC:

Q: How to boot from USB device?
A: Warning, this is still an experimental feature. Especially TWRP seems to have some issues with USB boot.

1. Follow the official instructions on how to enable USB boot on Pi 3 B (this step is not needed on Pi 3 B+)
2. Write image to your USB device as above
3. Mount the USB device on your computer and make following changes to /boot/config.txt under ‘Boot device’ section:
4. Plug in the USB device to your Raspberry Pi, remove any sdcard, and boot

Q: How to boot to TWRP recovery?
A: You can boot to TWRP by selecting recovery option in Android power menu after enabling advanced restart options.

Also the previous method of executing following commands in ‘adb shell’/serial console/terminal still works:

If mouse cursor doesn’t appear, try replugging your mouse.

Q: How to boot out of TWRP recovery?
A: You can boot out of recovery by simply selecting reboot to system option in TWRP.

Q: How to update from previous LineageOS 17.1 build without losing data?
A:

1. Boot to TWRP recovery with the build you want to keep the data (see FAQ)
2. Plug in an external USB storage device and select ‘Backup’
3. Use ‘Select Storage’ to choose the USB device and ‘Swipe to backup’ (it’s only necessary to backup the data partition so you can uncheck other partitions to speed up the process)
4. Write new LineageOS 17.1 image to the sdcard following installation instructions
5. Boot to TWRP recovery with the new build (see FAQ)
6. Select ‘Restore’ and find the backup you created from the USB device (‘Select Storage’)
7. Make sure you only have data selected as partitions to restore (uncheck other partitions if available) and select ‘Swipe to Restore’
8. (Flash Google apps package/other add-ons you had previously installed)
9. Boot out of recovery (see FAQ)

Q: How to install Google apps?
A: Warning, installing gapps slows things down especially on low-end devices with limited amount of RAM such as this one. I would strongly recommend against installing Google Apps on this device. Raspberry Pi 3 doesn’t have enough memory to provide decent user experience with Google Apps.

1. Download open_gapps-arm-10.0-pico-xxxxxxxx.zip and save it to your device’s internal storage or use an external USB drive
2. Boot to TWRP recovery (see FAQ)
3. Install open_gapps-arm-10.0-pico-xxxxxxxx.zip from your selected storage
4. Wipe->Factory reset!
5. Boot out of recovery (see FAQ)

Merged commits not mentioned in the changelog.

8.11. changelog:

• initial device settings for various Raspberry Pi specific options (Settings -> System -> Advanced settings)
  • audio device option (HDMI/3.5mm jack/audio DAC)
  • display options (graphics drivers, display resolution, display rotation)
  • options for IR remote, hardware keys, and RTC
• simplify booting to/out of TWRP recovery (see FAQ)
• improve support for booting from USB devices (see FAQ, thanks to maxwen)
• improve support for RTC & IR remotes (see FAQ)
• add more options for rotating touch input on Waveshare SPI (ADS7846) touchscreens (thanks to mikenon)
• allow switching display off with power button
• map right mouse button to back key
• update to TWRP 3.4.0-1
• update to Mesa 20.2.2 and latest upstream version of drm_hwcomposer
• update to Linux 4.19.155 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
• Android security patch level: 5 November 2020 (merged)

13.8. changelog:

• bring back forced landscape orientation for portrait apps
• bring back support for running scripts from /system/etc/init.d/
• read resolution from /boot/resolution.txt
• fix issue with drm video playback
• initial support for SSH server
• update Mesa to 20.1.5
• update to Linux 4.19.139 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
• Android security patch level: 5 August 2020 (merged)

27.7. changelog:

• initial LineageOS 17.1 build
• hardware accelerated graphics
  • VC4 using Mesa 20.1.4 with drm_hwcomposer & minigbm gralloc
  • 1280x720 resolution
• update TWRP to 3.4.0-0
• update to Linux 4.19.134 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
• Android security patch level: 5 July 2020 (merged)

Previous builds:

• 3Collect information about your device
• 4Set up three new directories
• 5Customize the files
• 6Then build a test recovery image

Some tips on porting CyanogenMod to your own device

So you may come across a phone or tablet or whatever that does not yet have CyanogenMod available.

You've previously built CyanogenMod on your computer for another device or two, and you feel comfortable with the process. In fact, you've still got the source code standing by and are ready to tackle a big project.

Looks like this is your opportunity to shine!

Note:

For the purposes of this tutorial, all references to directories will assume you are in the root of the source code (ie, where you did the repo init), and folder names will be relative to there. If you followed the build guide, the root of the source code is at ~/android/system

Prerequisites

Porting CyanogenMod to a new device can be ridiculously easy or ridiculously difficult, depending on the device itself, whether it currently runs a recent version of Android or not, and of course your skills as a developer matter too.

It would be pretty hard to do a port without having built CyanogenMod (and recovery) previously for another device. So if you haven't done a build or two, give it a shot.

Helpful Tip

If you found this page other than via the CyanogenMod Learning Center, head over to Development for much more information.

Additionally, you should familiarize yourself with the CyanogenMod source code. You should expect that, barring some rare exceptions, nearly everything you need to do will be in the /device/[vendor]/[codename], /vendor/[vendor]/[codename], and /kernel/[vendor]/[codename] directories.

Helpful Tip

For a more-detailed overview of what's where in the CyanogenMod source folders, see here. In fact, you really should read this if you plan on doing a port.

Collect information about your device

Before you begin your port, you will want to collect as much information about your device as you can. Go to wikipedia and identify the product name, code name, architecture, memory size, internal storage size, and platform architecture. Put this information in a file for easy retrieval. Try to learn as much about the device, including any similarities it may have to other devices.

Helpful Tip

Many devices are architecturally similar to other devices that are already on the market and have existing CM ports. When a new device comes out, see if you can find out if it may be identical to another device, only with a different sized screen or more memory or some other minor difference. If you find an 'ancestor' or 'sibling' of your device, much of the work may already be done for you!

Much of the information you need may be available online, but assuming the device is already running a non-CyanogenMod version Android, you may also get some of that information from the device itself. To view the files containing this information, the device may need to be rooted. However, sometimes you can find a stock firmware update package online, and can view the files from the .zip archive file.

Look at the device's current /system/build.prop

Assuming the device is already running a version of Android, there should be a file, /system/build.prop, on the device which may contain useful information that will come into play as you do your port. This file contains definitions for various parameters and settings used by Android.

So, if you have previously installed adb onto your computer, you can use the following command to pull this file to your computer:

adb pull /system/build.prop

If you receive an error relating to permissions, the device may need to be rooted to gain access to this file. However, there are other ways to locate this file. For example, it may be included in any stock firmware 'upgrade' package online.

Once you have the file...

• Write down the value of the ro.product.manufacturer parameter. This will be your vendor name. The [vendor] is the name of the manufacturer/vendor of the device. CM has established naming conventions for most major vendors, such as samsung, htc, lge, etc. Note that in these directory names, the vendor is always lowercase and contains no spaces.
• Write down the value of the ro.product.device parameter. This will be your device codename. The [codename] corresponds to the project code name of the device itself. This is almost never the sales name of the device. If you have built CM before (and again, you better have!), you should be familiar with the concept of a code name for each device. Like the vendor name, the codename is always lowercase and contains no spaces.

Note:

Sometimes a device is identified in other parameters such as ro.product.board

Keep the build.prop file handy, as you may refer to it later.

Examine boot.img and recovery.img

As stated, when doing your port, you may wish to use an existing pre-built kernel that you know works instead of building one from source code. Depending on your device, you may need to extract this kernel file from the device. The kernel may exist as a single file (as it does on many OMAP devices) or may be wrapped up along with the ramdisk in a boot or recovery partition.

Similarly, the contents of the stock ramdisk may be extremely helpful and can often be extracted and reviewed. It may be the case that a device requires specific files from the stock ramdisk in order to boot properly, load a module, etc. In most cases you can view files in the ramdisk from the device itself, but it you may prefer to look at the full directory.

Note:

The ramdisk is a tiny group of files and directories that are loaded into memory along with the kernel. The kernel then runs one of the files in the ramdisk called init, which then runs a script (init.rc, init.[codename].rc, etc.) that in turns loads the rest of Android. The ramdisk and kernel can be packaged together in a number of different ways using tools with names like mkbootimg, mkimage, and other methods.

You can frequently extract the boot and recovery images (to a file you name boot.img and recovery.img) on a rooted Android device using dd. Or, if you have access to an update .zip file from the vendor, you can often find those files within.

Collect any available existing source code

The manufacturer or vendor of any device using Android will minimally need to make the source code available for all GPL components upon request, including (and especially) the kernel. You definitely want to request a copy of the kernel source and keep it handy.

Determine the partition scheme

The primary long-term storage portion of your mobile device-- usually an 'emmc' (embedded multimedia card)-- is much like a computer hard drive in that it is prepared in a particular way to identify and isolate different areas of data. These unique areas are called partitions and they can have any kind of data stored there. Some partitions contain raw data-- firmware, kernels, ramdisks, etc. More often, a partition is formatted to use a particular file system that the kernel will recognize so that individual files and directories can be read and written there.

Before you can replace the stock operating system with CyanogenMod, it is therefore important to ascertain the partition scheme of the device. The recovery image you build will need this information to know where to find the various Android directories. Particularly, you want to know which partitions are assigned to /system, /data, /cache, and /sdcard.

You want to know which partitions exist, on what device, how they are mounted, as well as the size of the partitions. This information may be transferred later to the BoardConfig.mk file in your /vendor directory.

If you're lucky, a recovery.fstab file can be located in a recovery.img file, speeding up the process of figuring out what goes where. Also, the init.[codename].rc file in the ramdisk may have the information. Look for the lines near the top where the partitions are mounted.

Also, the command:

$ cat /proc/partitions

from a running device can also help you identify the partitions. Also see /proc/emmc, /proc/mounts or /proc/mtd. You may also get some information from the command mount (run as root).

Also check /cache/recovery.log or /tmp/recovery.log.

Finally, if you have source code to the bootloader (such as the u-boot used by many OMAP-based devices), you will likely find the information there as well.

Note:

Be aware that in some rare cases, such as the HP Touchpad, an abstracted virtual file system is used.

Set up three new directories

Now that you've gathered information about your device, it's time to generate the folders for your device configuration, located in the following directories, relative to the code source directory.

• device/[vendor]/[codename]/ -- this is where the installation files specific to your device will go. The device/ directory contain 99-100% of the configuration settings and other code for particular devices. You'll get to know this directory pretty well. As mentioned, when starting the folder for this device, it may be a good idea to adapt a directory for an existing device that is architecturally similar to the one you wish to port. Look for a device that is based on the same platform, for example.

• vendor/[vendor]/[codename]/ -- The vendor/ directory contains proprietary, binary 'blobs' that are backed up from the original device (or provided by the vendor, such as in the case of Google Nexus devices and some TI graphics blobs).

• kernel/[vendor]/[codename]/ -- the kernel source goes here. When you first start your porting effort, you may wish to simplify things by using a pre-built kernel (such as the one that came with the stock installation) rather than building the kernel from scratch. The trick to that will be extracting the kernel out of the stock system from whatever format it may be in, and then re-packaging it, along with a new ramdisk, into a form that your device can use. This can vary from device-to-device, so it may again be helpful to look at similar devices to yours that use a similar architecture. Building the kernel from source is not strictly necessary for every device, but in the spirit of open source, it is the preferred practice for CyanogenMod. See here for a detailed discussion about how CyanogenMod builds the kernel source from scratch.

There are at least three methods to generate these directories:

Method 1: Use mkvendor.sh to generate skeleton files

Use the mkvendor.sh script in build/tools/device/ to automatically generate the directories.

Note:

The mkvendor script only works with devices that use a standard boot.img file, using the standard Android conventions and headers. It won't work for devices that deviate from this standard (Nook Color, Touchpad, etc.).

This script accepts three parameters: vendor, codename, and a boot.img file.

Example usage:

In the above example, samsung represents the vendor, i9300 represents the codename and the last parameter is the path to the boot.img file that was extracted from the boot partition with dd or provided by the vendor in an update .zip as discussed above.

The command above should create a /device/samsung/i9300/ folder within your CyanogenMod source repo structure. And inside the folder, the files AndroidBoard.mk, AndroidProducts.mk, BoardConfig.mk, cm.mk, device_[codename].mk, kernel (the binary), recovery.fstab, etc.

This will not build the kernel/ directory. You will need to do that later, when you are ready to build the kernel.

Note:

If it returns the message 'unpackbootimg not found. Is yourandroid build environment set up and have the host tools been built?' please be sure that you run the following command during setting up the developer environment:

$ make -j4 otatools

Method 2: Fork a similar device's git repository

If you've got a GitHub account, you might want to start by forking another, similar device, and then rename it for your device. See the section on setting up github for a discussion on how to name your repository.

Always be sure you're compliant with the license of any repository you fork.

Method 3: create the directories and files manually

You can always start with an empty directory and start creating the files by hand. This is the least recommended and perhaps the most tedious method, but it may be the most instructive. You can look at other devices for reference on what files you need.

Customize the files

There are many files in the device/ folders. We will start by focusing on four files BoardConfig.mk, device_[codename].mk, cm.mk, recovery.fstab, and kernel to get recovery working for your device.

Helpful Tip – Start with the recovery!

The first major step is to get a working recovery image for your device so that testing subsequent update.zips is easy and so that you can do backups if necessary. These next few steps will therefore focus more on getting a working recovery than getting CM itself to work. Once the recovery is built and operating safely, the work you've done for it will apply directly to the CM part.

Lets examine each of these files:

BoardConfig.mk

This file contains vital architectual and build information about the architecture of your device's motherboard, CPU, and other hardware. Getting this file right is essential.

To get a basic recovery booting, a few parameters need to be set in this file.

The following parameters must be set properly in BoardConfig to compile a working recovery image:

• TARGET_ARCH: this is the architecture of the device it is usually something like arm or omap3.
• BOARD_KERNEL_CMDLINE: not all devices pass boot parameters however if your device does this must be filled out properly in order to boot successfully. You can find this information in the ramdisk.img. (You can learn more about configuring the integrated kernel build-from-source here.)
• BOARD_KERNEL_PAGESIZE: the pagesize of the stock boot.img and must be set properly in order to boot. Typical values for this are 2048 and 4096 and this information can be extracted from the stock kernel.
• BOARD_BOOTIMAGE_PARTITION_SIZE: the number of bytes allocated to the kernel image partition.
• BOARD_RECOVERYIMAGE_PARTITION_SIZE: the number of bytes allocated to the recovery image partition.
• BOARD_SYSTEMIMAGE_PARTITION_SIZE: the number of bytes allocated to the Android system filesystem partition.
• BOARD_USERDATAIMAGE_PARTITION_SIZE: the number of bytes allocated to the Android data filesystem partition.

Note:

The above information can be obtained by multiplying the size from /proc/partitions or /proc/mtd by the block size, typically 1024.

• BOARD_HAS_NO_SELECT_BUTTON: (optional), use this if your device needs to use its Power button to confirm selections in recovery.
• BOARD_FORCE_RAMDISK_ADDRESS / BOARD_MKBOOTIMG_ARGS: (optional), use these to force a specific address for the ramdisk. This is usually needed on larger partitions in order for the ramdisk to be loaded properly where it's expected to exist. This value can be obtained from the stock kernel. The former is deprecated as of Android 4.2.x and the latter will now be used in 4.2.x and beyond.

device_[codename].mk

The device_codename.mk makefile contains instructions about which Android packages to build, and where to copy specific files and packages, or specific properties to set during your compilation.

This file can be used to copy vital files into the ramdisk at compilation time.

• PRODUCT_COPY_FILES: used to copy files during compilation into the ramdisk, which will be located at $OUT/recovery/root.

Example:

This will copy the file offmode_charging binary into the sbin folder within the ramdisk.

• PRODUCT_NAME / PRODUCT_DEVICE: used for setting the value of your codename. This is the name of the device you load with Lunch.

kernel

This is simply the prebuilt kernel image or a kernel you built yourself used to boot the device. The format of the kernel may be in a zImage or uImage, depending on the requirements of the architecture of your device.

cm.mk

You'll need to make a few changes to this file to integrate with the lunch, brunch, and breakfast commands, so that your device shows up on the list and builds properly. You'll also set some variables (see other devices) to indicate what size splash animation should be used, whether this is a tablet or phone, etc.

Some of these settings aren't used for building just the recovery, but you may as well set them now because once recovery is done and working, the settings here will be important.

Again, take a look at a similar device to yours to get an idea of what the settings here should be. It's fairly intuitive.

recovery.fstab

recovery.fstab defines the file system mount point, file system type, and block device for each of the partitions in your device. It works almost exactly like /etc/fstab in a standard Linux operating system.

Example:

This sets the block device at mmcblk0p32 to be mounted on /system as filesystem type ext4

All mountpoints should exist in this file and it is crucial this information be correct or else very bad things can happen, such as a recovery flash writing to the wrong location.

Note:

The filesystem type datamedia can be used for internal sdcards as well as setting the block device to /dev/null.

vendorsetup.sh

vendorsetup.sh is called when setupenv.sh is run. It is used to add non-standard lunch combos to the lunch menu.

To add your device to the lunch menu:

Then build a test recovery image

Lineage Power Port Devices Drivers

To build only the recovery, set up lunch as with a regular build, and say make recoveryimage

If things break (and they will break), have a look at these tips for dealing with build errors.

Helpful Tip

If you have fastboot, you can try it to install the recovery image to the recovery partition. There are other methods for installing the recovery, such as using dd from a rooted system to flash it into place.

Not much needs to be said here, but make sure the recovery is working before you move on to getting CyanogenMod working. A 100%-working and reliable recovery mode is absolutely necessary before you start testing experimental Android builds.

Adjust recovery_ui.cpp if necessary

You may discover that although the recovery image runs, some of the hardware buttons, such as the volume buttons or power buttons, which would normally be used to scroll through the options, don't work.

You may need to adjust the GPIO values to get the buttons to be recognized. Similarly, you may wish to include/exclude options or modify other UI elements.

To do this, you may wish to create and edit the /device/[vendor]/[codename]/recovery/recovery_ui.cpp. You can find ample examples of this file, the associated recovery/Android.mk file that builds it, and how it is used.

Helpful Tip

The GPIO values for your device may be found in the kernel source.

Put your device folder in github, and use a local manifest to automatically sync it with repo sync

Once you've started your device folder, create your own GitHub account and set up your folder as a public GitHub repository. This is a great opportunity to learn about git, and also your source can be accessible to others who can collaborate with you.

When naming your repository, use the format android_device_VENDOR_CODENAME, where VENDOR and CODENAME use the new device's values. So, let's say your GitHub account name is 'fat-tire' and your device codename is 'encore', manufactured by Barnes and Noble. You should call your repository android_device_bn_encore. It would be accessible at https://github.com/fat-tire/android_device_bn_encore. Similarly, the kernel repository would be called android_kernel_bn_encore. It would be accessible at https://github.com/fat-tire/android_kernel_bn_encore.

The last thing to do is create a local manifest for other people to use to automatically download and their keep up-to-date with your changes. Here's an example, using the above scenario:

Note:

The revision attribute is optional. If it is omitted, repo sync will use the revision specified by the <default ... /> tag in the default manifest.

Once you've tested that the local manifest file works, you can pass it on to others, who can then try out your work. At that point you can continue to push your changes to GitHub, and even give other users commit access so that you can work on the device together.

Helpful Tip – Using other repositories

If you find that for some reason you need to replace or supplement other repositories provided by CyanogenMod, you can add additional repositories using the local manifest. Once you've got everything working, you can use Gerrit to submit stuff found in those repositories back upstream to CyanogenMod.

Add the blobs to the vendor/ directory

Once you have a working recovery, it's now time to get CyanogenMod building and working.

The first thing to do is to get all the proprietary, binary blobs into the vendor/ folder, along with a .mk file that will include them in the final build.

This requires three steps:

1. Create extract-files.sh and setup-makefiles.sh scripts to pull those blob files from the device using adb and put them in the right /vendor/ directory. There are plenty of examples available for other devices.
2. Create an .mk Makefile to copy those files to the $OUT folder during the build process and put them in the right place. Again, use other devices as a guide for what this Makefile should look like. An example filename might be BoardConfigVendor.mk
3. Make sure that the Makefile you just created is included from your main BoardConfig.mk via a command such as -include vendor/[vendor]/[codename]/BoardConfigVendor.mk. Again, existing devices can illustrate how this is done.

Now revise the device/ directory

Since you have a working recovery, go back and start modifying the files in the device/ folder. As always, use other similar devices as a reference.

You now have a easy means to do backups and test your builds. So start tweaking the device folder itself, and see if you get it to boot... Once you do, from there its a matter of building and supporting the various parts and peripherals, one-by-one.

Getting help from the manufacturers & vendors

Many of the OEMs (Original Equipment Manufacturers) who make the underlying platform used by your device frequently provide wikis, documentation, and sample code that can assist you in completing your port. You'll find that some companies are more friendly to the development community than others. Here are some of the more common OEMs and vendors, along with web sites and repositories that may help.

(This list is incomplete. Please help add to it)

Sometimes if you have questions you can even reach out to the developers via email or the support forums.

Adding XML Overlays

It's very likely in your device_[codename].mk file, there's a line that looks like this:

What this does is set the overlay/ folder to allow you to override any XML file used by Android frameworks or apps, just for this device. To do so, create a directory structure which mirrors the path leading to an XML file, starting from the root of your source. Then replace the file you want to overlay.

Example: Let's say you want to override some standard Android settings. Look at the file in frameworks/base/core/res/res/values/config.xml. Then copy it to device/[vendor]/[codename]/overlay/frameworks/base/core/res/res/values/config.xml. Now YOUR version will be used instead of the other one. You only need to include the settings you wish to override-- not all of them, so you can pare down the file to those few that change from the default.

You can overlay any XML file, affecting layouts, settings, preferences, translations, and more.

Make the kernel and kernel modules build from source

If you have previously used a pre-built kernel, you may at some point want to start building the kernel from scratch.

See the instructions for how to change the BoardConfig.mk file to make CyanogenMod build the kernel and any required kernel modules automatically.

Conclusion

There's no way a single wiki page will tell you everything you need to know to do a port from beginning to end. However, hopefully you now have an understanding of how things are set up and the steps you need to take. You an always ask for help on the forums or on IRC. Others with the same device may jump in to help too.

Hopefully you'll find the process rewarding and educational. And it'll get you some street cred as well.

When you're all done, and your port works better than stock... when it's stable and shiny and marvelous and wonderful...

You may want to contribute your work upstream. Here are the instructions for how to do just that.

Good luck!

Lineage Power Port Devices Driver Windows 7

See Also

• Android-Porting -- the official Google Group on this topic
• General CyanogenMod Porting Discussion -- a forum post on porting

Lineage Power Port Devices Driver Updater