Skip to content

Heavily edits README.md while closing JackpotClavin/Android-Blob-Utility#7 #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
coc0a wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Heavily edits README.md while closing JackpotClavin/Android-Blob-Utility#7 #9

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3be1c04
Edited README.md for clarification.
coc0a May 14, 2017
0d3d4cd
Edit #2
coc0a May 14, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 41 additions & 32 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,59 +2,68 @@ Android Blob Utility
=============================
by JackpotClavin

About
=============================

The Android Blob Utility is a program designed to make developing AOSP-based
ROMs easier for developers. What is does is it allows the developer to pick
proprietary file, type the file's absolute path, and this program will spit
back every library that should be needed in order to get that library or daemon
ROMs easier. What it does is it allows the developer to pick
proprietary files, type in the files' absolute paths, and this program will spit
back every library that is needed in order to get that library or daemon
to run on an AOSP ROM.

How does it work? First the developer must dump their entire stock ROM's
How does it work?
=============================

First, the developer must dump their entire stock ROM's
software to their computer, so that typing the command:
`$ ls /home/android/dump/build.prop` will yield their device's build.prop.
This is just meant to ensure that you have the correct path it is valid.
`$ ls /path-to-build.prop/build.prop` will yield their device's build.prop. This is just meant to ensure that you have the
correct path. This dump can be can be obtained by doing `adb pull /system /path-to-destination/` with the device connected to
the computer, replacing `/path-to-destination/` to wherever you want to store the dump.
Next, you are to compile this program with the `make` command. Once you run it,
the program will prompt you to enter whatever the SDK version of you /system
dump happens to be (check your /system/build.prop), for instance if your
the program will prompt you to enter whatever the SDK version of your /system
dump happens to be (check your /system/build.prop); for instance if your
/system dump is Android 4.3, type in `18` (use the following site for
[guidelines](https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels)).
Secondly, the program will ask you for the location of your /system dump; so if
the build.prop file is under `/home/android/dump/build.prop`, you can just type:
`/home/android/dump` and press enter. Then the program will prompt you for the
manufacturer name and device name. In the case of my Verizon LG G2, when
prompted for the manufacturer(vendor) and device name, I inputted `lge`, and
`vs980`, respectively. For the third step of getting the necessary blobs,
this program will prompt you to enter however many blobs files you want this
[guidelines](https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels)).
Third, the program will ask you for the location of your /system dump; so if
the build.prop file is under `/home/android/dump/build.prop`, you can just type
`/home/android/dump` and press enter. The program will prompt you for the
manufacturer and device name. In the case of my Verizon LG G2, when
prompted for the manufacturer(vendor) and device name, I typed in `lge`, and
`vs980`, respectively.
For the fourth step, getting the necessary blobs,
this program will prompt you to enter the amount of blob files you want this
program to process. If you want to only process one blob, type `1` and hit
enter. After you enter the amount of blobs you want this program to process, you
will type the absolute path to the actual blob (see the [example program usage]
(https://github.com/JackpotClavin/Android-Blob-Utility/blob/master/Example_Usage.txt)),
type the absolute path to the actual blob (see the [example program usage](https://github.com/JackpotClavin/Android-Blob-Utility/blob/master/Example_Usage.txt)),
and this program will print out all of the proprietary blobs that are mentioned
in that particular blob that you entered, that aren't in the emulator's /system
dump. That means that those files are either have to be built from source, or
in that particular blob, that aren't in the emulator's /system
dump. This means that those files are either have to be built from source, or
are proprietary and must be copied into the ROM's build. This program will also
format the blobs such that it is ready to be placed into a vendor-blobs.mk file
in your vendor folder of the ROM's source tree root.
format the blobs so that it is ready to be placed into a vendor-blobs.mk file
in your vendor folder in the root of the ROM's source tree.

Features
==============================

What makes this program great is that it doesn't just get the shared libraries
necessary to appease the linker, but it takes another step; it also catches the
blobs that may slip past the linker because they are called in the actual code
necessary to appease the linker, but it goes another step, also catching the
blobs that may slip past the linker because they are only called in the actual code
of the blob. Simply copying the shared libraries just appeases the linker, but
the blob still not run properly as the blob may want additional libraries.
the blob still may not run properly as the blob may want additional libraries.

This program also searches recursively, so each and every blob that is found is
also processed through the searching algorithm, to see which blobs *that*
also processed through the algorithm, to see which blobs *that*
library also needs to run, so we cover all of the bases in order to get a
proprietary library or daemon to run.

The following example was used on my LG G2. Running this program with the two
The following example was copied from LG G2. Running this program with the two
main proprietary files related to the camera `/system/bin/mm-qcamera-daemon` and
`/system/lib/hw/camera.msm8974.so`, this program nicely printed out *every*
proprietary file needed to get the camera working, and formatted it so that one
proprietary file needed to get the camera working, and formatted it so that anyone
can easily copy the program's output to a vendor-blobs.mk file, instead of
having to keep pushing files until the linker is satisfied, or having to find
libraries that aren't shared libraries, but are called in the actual code of
the proprietary file.

having to continuously push files until the linker is satisfied, or having to find
libraries that aren't shared libraries, but are called in the actual code (of
the proprietary file).
Example program usage can be found in the [Example_Usage.txt](https://github.com/JackpotClavin/Android-Blob-Utility/blob/master/Example_Usage.txt)
in this folder.