Related
Update 7 May 2012: New version released, containing PHP 5.4.2 with curl / openssl modules built in (still for armv5). Besides the version number, installation steps remain the same.
Introduction
The web page of the project, containing more information, licenses, configuration fils, list of modules for php and lighttpd, etc is here:
http://hex.ro/wp/blog/php-and-lighttpd-for-android/
It also contains and example, how to install SMF forum onto the phone
Download
This comes with NO WARRANTY. Use it at your own risk!
php-5.4.2_lighttpd_1.4.29_armv5.tar.gz
php-5.3.8_lighttpd_1.4.29_armv5.tar.gz
Installing
After you copy the archive above into the root of your SD Card, installation is easy:
Code:
cd /
tar xf /sdcard/php-5.3.8_lighttpd_1.4.29_armv5.tar.gz
reload-fcgi.sh
reload-lighttpd.sh
Make sure you are on the root file system (/) before executing tar command.
Also, mandatory: rooted phone + busybox + /system partition mounted read only.
Below information is older - which was before the bundle was ready
Coming soon:
(excerpt from phpinfo() now running on my phone)
PHP:
System Linux localhost 2.6.32.9-perf #1 PREEMPT Fri Jul 8 13:45:08 2011 armv7l
Build Date Aug 30 2011 22:07:32
...
PHP Version 5.3.8
...
Server API CGI/FastCGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /system/etc/php
Loaded Configuration File /system/etc/php/php.ini
...
_SERVER["_"] /system/bin/php
_SERVER["FCGI_ROLE"] RESPONDER
_SERVER["SERVER_SOFTWARE"] lighttpd/1.4.29
_SERVER["SERVER_NAME"] 192.168.1.3
_SERVER["GATEWAY_INTERFACE"] CGI/1.1
I have managed to compile lighttp 1.4.29 with fcgi support as well as php 5.3.8 (both latest version).
All graphics libraries are in as well as SQLite.
I will still have to play with OpenSSL to get it running. Maybe MySQL in the future
It will take a while to set everything up (a web page for source code, wiki on how to install), but we're close to have a fuller Linux experience on Android powered phones.
This would be amazing, I've been hoping for something like this.
wow, I'm really looking forward this
It's cool to have this functionality, cuz sharing files via BT is a pain the ass
I'm waiting too. And wish you luck. Thanks for the efforts.
Thank you for the kind words
Yes, everything works now, and I've tried out a PHP gallery as well as PHP file editor (so you can edit .php files within Opera connected to local host).
It works. Unfortunately, on my Arc, it takes about 3 seconds to generate a thumbnail of a camera image. Now I understand why the whole thing with Media Server indexing files first time after reboot, when phone is slow and etc .. and why the need that apps have to notify Media Server to index additional files when apps create them. So by the time user gets to open the gallery, their thumbnails are already there (it masks the delay).
I want to try out more scripts and then create an installer for the whole thing. If members here report it works, then I will upload it to the market.
I think I will try a bunch of forum engines.
How many additional modules will there be? ImageMagik is really useful… or at least GD
EDIT: ohh, didn't see OP says all graphic libraries included (^_^; )
viulian said:
Thank you for the kind words
Click to expand...
Click to collapse
We should thank you for your efforts. And we are.
viulian said:
I want to try out more scripts and then create an installer for the whole thing. If members here report it works, then I will upload it to the market.
Click to expand...
Click to collapse
You can count on me. I'm not a full time PHP developer, but I wrote few little "systems" in "my way" so it should test non-standard approach at least. but I believe you've already tested basic PHP behaviour
By the way - you mentioned something about mysql... I would personally prefer PostgreSQL, but I do not know anything about a way it's written so theoretically it can be harder to move to arm platform. Postgres is more flexible in many ways, and sometimes (I've heard) a way faster because of simplicity of mysql.
But if anything will be problematic with sql, I can always fall back to sqlite
Update:
libcurl won't be bundled (PHP will be compiled without --with-curl argument).
It seems that libcurl has a dependency on libc - and it tries to load libc.so causing php executable to crash.
Output from strace:
Code:
open("/system/lib/libc.so", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=273912, ...}) = 0
close(3) = 0
--- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xfde0004} (Segmentation fault) ---
+++ killed by SIGSEGV +++
Segmentation fault
that's really sad. cURL is sooo cool. (´Д`)
but so far you always found a way to make things work and I hope the same will apply to this as well.
If you have an idea that would work, then will this released later? or you let us play with the cURL-less boundle?
I won't mind lacking of cURL. We have wget onboard for simple downloads. For more sophisticated actions android isn't the best platform
Here's the info.php generated using lighttpd / php statically built for Android:
info.php.zip
I've been on a trip with limited access to internet, and so far I managed to find a fix for lighttpd which, when statically built, would not load the modules in the correct order. It was a mess to use I've documented it here: http://redmine.lighttpd.net/issues/2343
ImageMagick is not ported yet (just standard gd as you will see). I'm tempted to port ImageMagick also, since it seems that batch operations are faster with it than with the built in gd (and on my Arc, generating the thumbnail of a camera taken photo takes about 3 seconds, which is slow).
So far I've tested fotogallery and monoedit (to edit php files on the phone using any browser) and they work fine.
Please expect updates soon.
I've just managed to cross-compile ImageMagick for Android, and it takes mogrify about 4.2 seconds (on my Arc) to create a 120x90 px thumbnail for a 1.8Mb photo from the camera.
Code:
[[email protected]]/sdcard/DCIM/100ANDRO# time mogrify -path thumbs -thumbnail 120x90 DSC_0172.jpg
real 0m4.176s
user 0m3.950s
sys 0m0.130s
Also, each executable has about 5.3Mb when statically linked (convert, mogrify, etc...) which makes the ImageMagick bundle to around 57Mb in total (which is huge).
Thus, no ImageMagick for now waiting for better hardware.
When will you release any alpha to allow us killing it?
I'm working on a web page on my blog where I'll present everything - and will post an update here. If not later tonight, then tomorrow I'll release it.
For now it is compiled for armv5 CPUs (meaning it will work on many phones, even older and slower ones). I've tested it on a Sony X10 Mini (MSM7227, 600Mhz, ArmV5) and Sony Arc (MSM8255, 1Ghz, ArmV7) and works a treat!
Also installed SMF (Simple Machines Forum with sqlite) and it works.
Great . I'll try it as soon as you publish it
krzych said:
Great . I'll try it as soon as you publish it
Click to expand...
Click to collapse
Please check first post and let me know! I've just released it.
i think max request size is too small
it will make 413 error when try to attach file
default value is 2Gb but i think viulian set too small value (even i can't attache 250kb jpg )
if someone want to increase it
add this lines on your lighttpd.conf
server.max-request-size=10240
server.network-backend=”writev”
server.upload-dirs=( “/sddata/www/tmp” )
size=kb
dirs=must same as upload_tmp_dir on your php.ini
there are my config files
Thank you for the updates
Both php and lighttpd come with the default values - I did not change anything ... (in an attept to offer as much as possible the Linux experience with them, when you have to reconfigure things).
The only change I did was to set the temp folder for php to /data/local/tmp (although your suggestion to use the /sdcard might work out better in case of a lot of uploads since the /data space is limited compared to /sdcard).
i also think sdcard is better but /sdcard can't save permission and ownner
it's big secure hole
i think sd-ext is best
i compile the execwrap
using by gcc for android (you can download from here (you can extract from main files from https://market.android.com/details?id=com.n0n3m4.gcc4droid&feature=more_from_developer)
you can find documents about execwrap from lighty's site
I recently looked into stagefright support in ffmpeg and vlc and found that one of the chore they have is having platform headers to compile against around. Actually, they didn't work for me at all - likely because they were written for one Android version, and I run them on the other. Again, if supporting compilation against even one (random) Android version is a chore, who can expect good support for multiple versions?
To fight against such poor state of things, I'd like to introduce android-platform-headers, which provides headers for all important Android versions side by side.
More info is in the README:
Code:
These are sets of header files extracted from main components of
AOSP (Android Open Source Project), for each main release of AOSP.
Android NDK provided by Google contains subset of AOSP platform
headers which are deemed "external interface" by Google. However,
writing advanced software for Android necessitates access to complete
platform. Many aspects of it change, sometimes drastically, between
releases, so compiling user source code against platform headers for
different releases is required. This project intends to streamline
this process, allowing to access headers for all important Android
releases at once.
In this respect, it is similar to "linux-kernel-headers" found in
many Linux distributions - it allows to compile software without
the need to have hundreds of megabytes (or gigabytes) of complete
kernel (or platform) source code around.
To prepare these headers, all *.h and *.hpp files were extracted
from following AOSP projects:
* system/core
* frameworks/base
* frameworks/native
FAQ
---
Q: Google doesn't recommend usage of non-NDK headers.
A: Who cares.
Q: As these headers don't represent external interface, they can be
changes by vendor of some device.
A: True, so we can figure out what particular vendors work on -
on bringing up innovative products, cutting time to market, increasing
power efficiency, or fragmenting platform and breaking compatibility.
Q: How do I know that headers provided are correct?
A: You are encouraged to verify. Each header project directory contains
.git-org/refs/heads/master with revision of tag from which it was extracted.
Actually, extraction was automatic and script is provided. To easily verify
a particular tag:
rm -rf android-1.6_r1
scripts/fetch-headers android-1.6_r1
git diff
TODO
----
1. Add platform "import" libraries to link with (devoid of code, only with
exported symbols).
2. Similar "implib" jars to link Java code against.
Status update: repo now contains platform headers for the most popular Android versions from 1.6 to 4.2, and started to work on scripts to produce "import libraries" to link native apps against.
Questions? Use Q&A!
Please read the FAQ before reporting any bugs or errors!
If you post in the main thread not having read the FAQ or error message itself, not included a debug log when reporting a malfuction or reporting a Force Closure without a logcat, your post will be ignored by the developers!
Not because we are evil, but because the same questions keep popping up over and over again and too often we get a "X doesn't work, plz fix" without any clue what is happening. We don't have telepathic connection to your device and all the time unnecessarily wasted on this can't be spend on development of Open GApps itself.
The Latest builds of Open GApps for Android can easily be downloaded from the:
Open GApps Homepage -> All architectures & download options
Open GApps App
FAQ @ GitHub
Package comparison @ GitHub
Advanced Features and Options @ GitHub
Development Repository @ GitHub
I work on this project for FREE and putting in a lot of hours into it. While not mandatory, donations encourage me to continue to further pursue this project and I'd deeply appreciate them, if you feel generous.
Donate to The Open GApps Project
Are you a ROM developer and want to hotlink to the latest Open GApps package? Then check this wiki entry for details.
Please don't publicly mirror the prebuilt packages without explicit consent of @MastahF, to ensure that users will always be directed to the very latest version and the source code of the project.
About The Open GApps Project
Open GApps is a Google Apps package completely developed by writing buildscripts which allow for the automated creation of new up-to-date packages automatically.
The development process is completely open-source (GPLv3) and the goal is to have multiple contributors involved, to secure and reinforce the sustainability of Open GApps development.
Builds are generated every (European) night automatically (if there are any changes) and uploaded to GitHub.
Official AROMA Open GApps package is developed in collaboration with long-time LP-AROMA-developer @raulx222 and has a dedicated XDA thread
For any questions about the AROMA installer development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.
Official Open GApps For Stock support is developed in collaboration with @Rapper_skull and has a dedicated XDA thread
For any questions about the GApps for Stock development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.
The x86 package branch of the package is focused on Zenfone support and is maintained by @deadman96385 of the famous Zenfone GApps packages and has its own topic for x86 related questions
For those that cook their own ROM, an AOSP-build mechanism for Open GApps has been developed by @blystad and can be found at GitHub, remember that you should not bundle any pre-packaged Google Apps with any ROMs you want to distribute further though.
To gather all the various APKs that are necessary for the packages our master of the APK Universe @MNBooZe has written a tool called APKCrawler that scrape these from the internet, e.g. from APKMirror, it can be found at GitHub too.
Characteristic of Open GApps:
Some highlights about the characteristics of the Open GApps packages:
All platforms and and all Android versions are supported
DPI-optimized support for all Google packages (unlike other GApps)
Frequently updated Google Apps: The pre-built OpenGApps.org packages are updated every (European) night (if there are any updated Google Apps available)
Strong compression, allowing for relatively small downloads of even the most complete packages
Automatic backup: It is not necessary to re-flash Google Apps when you flash a ROM update. Most ROMs support this (addon.d) function
The installer checks your device’s capabilities, like the system partition size. It will notify you, before making any changes, if it finds any problems
Several package variations, from a Google Super Package (includes all applications that ever shipped on a Google device), to a Stock package that equals the set of applications found on the most current and complete Nexus, to smaller, minimalist packages and an AROMA package that allows graphically selection of what to install
A special ‘for Stock ROM’ installation mode that allows to update the Google Apps on Stock ROMs that conform to the original Google Nexus filesystem structure
All package installations can be customized to your individual preferences using our Advanced Features and Options
The idea behind this project:
I believe a big source of the problem for many GApps packages to stay up-to-date (or not be forfeited) is the lack of time for developers to do labour-intensive repetive every time a new google-app apk is released.
That is why I have taken it upto myself to write some Linux shell scripts to automate the packaging and to share these efforts with the world with the goal to create a team to continue this package together under the name Open GApps.
This project should not be managed by a person, but by a team, so volunteers willing to help are more than welcome!
Team management and projectleader: @[COLOR="blue"]MastahF[/COLOR]
Writing of the scripts: @[COLOR="blue"]MastahF[/COLOR] & @[COLOR="blue"]Rapper_skull[/COLOR] or check the team on GitHub and many other contributors
Updating GApp sources: @[COLOR="blue"]MNBooZe[/COLOR] & @[COLOR="blue"]DJAlik[/COLOR] & @[COLOR="blue"]bgiesing[/COLOR] & @[COLOR="blue"]mc1100[/COLOR] & @[COLOR="blue"]deadman96385[/COLOR] or check the team on GitHub
AROMA installer: @[COLOR="blue"]raulx222[/COLOR] using LibAroma
Custom compiled commandline tools: @[COLOR="blue"]YashdSaraf[/COLOR]
Website: @[COLOR="blue"]raulx222[/COLOR] & @[COLOR="blue"]MastahF[/COLOR] & signalv hosted by GitHub and created with Material Design Lite and JQuery
Artwork: @[COLOR="blue"]Yeti12[/COLOR]: Yeti-Designs website
Documentation: @[COLOR="blue"]Trafalgar-Square[/COLOR] and @[COLOR="blue"]MastahF[/COLOR] and many other contributors.
Open GApps installer uses open source third-party tools, like busybox and xzdec, compiled by @YashdSaraf; See his busybox thread for more info.
Open GApps is originally based on the now discontinued PA GApps package of @TKruzze and @osm0sis
I suggest to @hellowasif and @sir*mez to take a look at this
Hi, @provolinoo suggested me to take a look at this topic.
I made my own GApps, derived from PA GApps by TKruzze and without knowing I solved some problems that the people that were trying to continue the PA GApps are having.
I completely removed the sizes.prop file and now I measure the sizes of the apps on the fly using unzip. I took a look at your scripts and they're really useful, and reminded me that the APKs need to be zipaligned, which I forgot.
Maybe we can join your scripts, my changes, and a fast internet connection to bring PA GApps back to life.
If you're interested here's the link to my topic, please take a look at it: http://forum.xda-developers.com/android/general/alpha-gapps-stock-t3093389
Well i wanted to say thankyou so much for such wonderful work you did, Before this i was maintaining the PA-Gapps Packages PA Gapps 4.4.4 and PA-Gapps 5.X everything was going great and i must say i learned a lot by maintaining these Gapps packages and that was very wonderful experience but i was only updating Gapps and Libs, But than i realized that they weren't as perfect as the original gapps packages because the original Gapps package uses two important files which were size and libs list which the packages uses and they were the most important part of PA-Gapps. I tried to update these two files manually but they were two time consuming so i decided to drop this project due to lack of resources but by these scripts it will very easy to create Gapps Packages so i wanted to say thankyou again
Rapper_skull said:
Hi, @provolinoo suggested me to take a look at this topic.
I made my own GApps, derived from PA GApps by TKruzze and without knowing I solved some problems that the people that were trying to continue the PA GApps are having.
I completely removed the sizes.prop file and now I measure the sizes of the apps on the fly using unzip. I took a look at your scripts and they're really useful, and reminded me that the APKs need to be zipaligned, which I forgot.
Maybe we can join your scripts, my changes, and a fast internet connection to bring PA GApps back to life.
If you're interested here's the link to my topic, please take a look at it: http://forum.xda-developers.com/android/general/alpha-gapps-stock-t3093389
Click to expand...
Click to collapse
Hey, I looked at your work. Some things are indeed good improvements and I will try to incorporate them into my work if you don't mind.
I also looked at your sizes.prop solution, but honestly I don't like it that much, because although the calculation will be very exact, I don't think it is a good idea to unzip large files and pipe all this data through on our small little phones . I prefer to keep the sizes.prop estimations on the generating-side rather than on the execution-side.
I really would like you to be involved in the project, somebody else also already PMed on the forum, wanting to be involved. I described which tasks and roles are very welcome to be fulfilled within a joint team effort.
MastahF said:
Hey, I looked at your work. Some things are indeed good improvements and I will try to incorporate them into my work if you don't mind.
I also looked at your sizes.prop solution, but honestly I don't like it that much, because although the calculation will be very exact, I don't think it is a good idea to unzip large files and pipe all this data through on our small little phones . I prefer to keep the sizes.prop estimations on the generating-side rather than on the execution-side.
I really would like you to be involved in the project, somebody else also already PMed on the forum, wanting to be involved. I described which tasks and roles are very welcome to be fulfilled within a joint team effort.
Click to expand...
Click to collapse
Thank you for your appreciation. The files however are not extracted but I used "unzip -l" that lists the content of the archive with the file sizes. Keep me informed about this project.
hellowasif said:
Well i wanted to say thankyou so much for such wonderful work you did, Before this i was maintaining the PA-Gapps Packages PA Gapps 4.4.4 and PA-Gapps 5.X everything was going great and i must say i learned a lot by maintaining these Gapps packages and that was very wonderful experience but i was only updating Gapps and Libs, But than i realized that they weren't as perfect as the original gapps packages because the original Gapps package uses two important files which were size and libs list which the packages uses and they were the most important part of PA-Gapps. I tried to update these two files manually but they were two time consuming so i decided to drop this project due to lack of resources but by these scripts it will very easy to create Gapps Packages so i wanted to say thankyou again
Click to expand...
Click to collapse
Hi hellowasif,
would you be interested in collaborating then together with other people in a team to bring back PA Gapps using these scripts?
MastahF said:
Hi hellowasif,
would you be interested in collaborating then together with other people in a team to bring back PA Gapps using these scripts?
Click to expand...
Click to collapse
Yes that will be wonderful to work as a team and you count me in. :highfive:
Rapper_skull said:
Thank you for your appreciation. The files however are not extracted but I used "unzip -l" that lists the content of the archive with the file sizes. Keep me informed about this project.
Click to expand...
Click to collapse
Ah, then i misread your code, I will take a look at it then again. Anyhow, since the files in the package are static, I think at moment of generation is a good moment to get the file sizes
I have btw a question for you, a problem I was not able to resolve myself yet, even though trying a lot.
When creating the .zip-package to be signed and afterwards flashed, I am at the moment not using any compression (but use the -Z store flag).
If I use *any* kind of compression, the package refuses to flash at my phone (GT-i9300) with the message error executing update binary error.
I tried a lot of combinations, like using a different zip-application, compressing only the files outside META-INF etcetera, but nothing seems to work.
So my question is: how do you generate and sign your zip file? On which platform? With which application? With which parameters?
MastahF said:
Ah, then i misread your code, I will take a look at it then again. Anyhow, since the files in the package are static, I think at moment of generation is a good moment to get the file sizes
I have btw a question for you, a problem I was not able to resolve myself yet, even though trying a lot.
When creating the .zip-package to be signed and afterwards flashed, I am at the moment not using any compression (but use the -Z store flag).
If I use *any* kind of compression, the package refuses to flash at my phone (GT-i9300) with the message error executing update binary error.
I tried a lot of combinations, like using a different zip-application, compressing only the files outside META-INF etcetera, but nothing seems to work.
So my question is: how do you generate and sign your zip file? On which platform? With which application? With which parameters?
Click to expand...
Click to collapse
You will maybe laugh at my reply, but I simply use WinRAR, on Windows, with maximum compression. I do not yet sign the ZIPs because I wanted to generate my own private key instead of using the generic test-key. What you can try to do is update your recovery (if it's not updated) to see if the problem is solved.
dowloaded your GitHub project and ran through the scripts to create the signed zip file. So far everything is running smoothly. Did a full wipe. Great Job!
Question I have. Do you know why the com.android.vending is still installed in the user space (/data/app) vs system space?
Chrome doesn't seem to be working. It crashes every time I try to run it.
DJAlik said:
dowloaded your GitHub project and ran through the scripts to create the signed zip file. So far everything is running smoothly. Did a full wipe. Great Job!
Question I have. Do you know why the com.android.vending is still installed in the user space (/data/app) vs system space?
Click to expand...
Click to collapse
Thank you for your feedback, at the moment I was extracting the Play Store from a Nexus Image under the cryptic name of Phonesky.
I only found out just now that this Phonesky is the same as android.vending (the Play store) and updated this.
DJAlik said:
Chrome doesn't seem to be working. It crashes every time I try to run it.
Click to expand...
Click to collapse
Also thank you for your feedback. Using your feedback I discovered some nasty typos in my script which were breaking Chrome and Talkback.
I fixed those and will be uploading a new package later today. The fixes are already on github.
hellowasif said:
Yes that will be wonderful to work as a team and you count me in. :highfive:
Click to expand...
Click to collapse
Nice
Very happy to hear that! Tomorrow I will be heading for an island for a week, for holidays, so lucky for me, but unlucky for those interested in updates .
After that holiday I will set-up the basic infrastructure for the team.
I also thought about how to make packages for older android versions and I came up with the following solution that I will be then implementing next week:
*Within the SourceAPKs folder we will put some meta-data or an overlay that specifies the minimal SDK/API version that the package requires
*I will update the scripts in such a way that you can target various android versions, including such a sdk/api version.
*When building for a target, the highest version of the APK that still support that sdk/api version will be selected
*A seperate output directory will be created for each target
*All scripts will be executed from a single Makefile
E.g., the directory structure will look like:
SourceAPKs/18/com.google.android.apps.maps-9.8.1-908101124-minAPI18.apk
SourceAPKs/14/com.google.android.apps.books-3.3.41-30341-minAPI14.apk
Scripts/extract_sources.sh
Output/4.4/pa_unsigned.zip
Output/5.0/pa_unsigned.zip
Output/pa_gapps-4.4-20150504.zip
Output/pa_gapps-5.0-20150504.zip
Makefile
If anybody has any feedback on these ideas, you are welcome!
MastahF said:
Nice
Very happy to hear that! Tomorrow I will be heading for an island for a week, for holidays, so lucky for me, but unlucky for those interested in updates .
After that holiday I will set-up the basic infrastructure for the team.
I also thought about how to make packages for older android versions and I came up with the following solution that I will be then implementing next week:
*Within the SourceAPKs folder we will put some meta-data or an overlay that specifies the minimal SDK/API version that the package requires
*I will update the scripts in such a way that you can target various android versions, including such a sdk/api version.
*When building for a target, the highest version of the APK that still support that sdk/api version will be selected
*A seperate output directory will be created for each target
*All scripts will be executed from a single Makefile
E.g., the directory structure will look like:
SourceAPKs/18/com.google.android.apps.maps-9.8.1-908101124-minAPI18.apk
SourceAPKs/14/com.google.android.apps.books-3.3.41-30341-minAPI14.apk
Scripts/extract_sources.sh
Output/4.4/pa_unsigned.zip
Output/5.0/pa_unsigned.zip
Output/pa_gapps-4.4-20150504.zip
Output/pa_gapps-5.0-20150504.zip
Makefile
If anybody has any feedback on these ideas, you are welcome!
Click to expand...
Click to collapse
The idea of automating all the process is certainly good, but we have to keep in mind that things changes really fast. For example in an update Google can add a library to an application that previously didn't have one. We have to check if there's a lib folder inside the APK instead of assuming that all the APKs that now don't have libs will never have them. Also the idea of various app versions is very good, but also error prone. Maybe we can just put all the APKs in one folder and use the filename to determinate the app name and the minAPI (if we don't want to make a step further and read directly from the AndroidManifest.xml, using aapt).
MastahF said:
Thank you for your feedback, at the moment I was extracting the Play Store from a Nexus Image under the cryptic name of Phonesky.
I only found out just now that this Phonesky is the same as android.vending (the Play store) and updated this.
Also thank you for your feedback. Using your feedback I discovered some nasty typos in my script which were breaking Chrome and Talkback.
I fixed those and will be uploading a new package later today. The fixes are already on github.
Click to expand...
Click to collapse
latest commit:
$ sh make_package.sh
rm: missing operand
DJAlik said:
latest commit:
$ sh make_package.sh
rm: missing operand
Click to expand...
Click to collapse
You can ignore that error-message. I just delete all the temporary files of my text editor (ending with a ~) before packaging using this 'rm' command.
Rapper_skull said:
The idea of automating all the process is certainly good, but we have to keep in mind that things changes really fast. For example in an update Google can add a library to an application that previously didn't have one. We have to check if there's a lib folder inside the APK instead of assuming that all the APKs that now don't have libs will never have them. Also the idea of various app versions is very good, but also error prone. Maybe we can just put all the APKs in one folder and use the filename to determinate the app name and the minAPI (if we don't want to make a step further and read directly from the AndroidManifest.xml, using aapt).
Click to expand...
Click to collapse
Very good comments. I have been looking into the possibility of using aapt. With 'aapt d badging file.apk' I will be able to retrieve the API information and app/packagename from any apk.
Using this information I could make an add-script or an 'add-directory' that would scan any new apks and archives them automatically in a storage. This could help to maintain overview, and to automatically discard older versions of the app if the api-level is not changed. It could also allow for adminstation of x86 and arm64 packages in the tree.
So a 'storage' filetree could become in that case like:
/arm/packagename/api14/maps2.apk
/x86/packagename/api11/maps1.apk
/x86/packagename/api14/maps2.apk
My goal is also to indeed in the future to (more) automatically process the existence of a 'lib' and automatically incorporate into the output process. For this I will have (as within my goals set out for next week) to upgrade the process of generating the output folder. Because at this very moment the scripts still assume availability of (most of the) outputfolders to be there already.
MastahF said:
Very good comments. I have been looking into the possibility of using aapt. With 'aapt d badging file.apk' I will be able to retrieve the API information and app/packagename from any apk.
Using this information I could make an add-script or an 'add-directory' that would scan any new apks and archives them automatically in a storage. This could help to maintain overview, and to automatically discard older versions of the app if the api-level is not changed. It could also allow for adminstation of x86 and arm64 packages in the tree.
So a 'storage' filetree could become in that case like:
/arm/packagename/api14/maps2.apk
/x86/packagename/api11/maps1.apk
/x86/packagename/api14/maps2.apk
My goal is also to indeed in the future to (more) automatically process the existence of a 'lib' and automatically incorporate into the output process. For this I will have (as within my goals set out for next week) to upgrade the process of generating the output folder. Because at this very moment the scripts still assume availability of (most of the) outputfolders to be there already.
Click to expand...
Click to collapse
Exactly, in this way it would be possible to easily maintain arm64 and x86 packages too. The scripting is not complicated, it just requires some time. If you want I can contribute too (I had some experience with shell scripting). If the final scripts are not too long or complicated we can plan a Windows port too, if some future team member is not used to Linux.
We can also try to contact AP to request an RSS feed for new APKs on APKMirror.
EDIT: It seems that adding /feed to any URL will give you the corresponding RSS feed. Good to know.
Rapper_skull said:
Exactly, in this way it would be possible to easily maintain arm64 and x86 packages too. The scripting is not complicated, it just requires some time. If you want I can contribute too (I had some experience with shell scripting). If the final scripts are not too long or complicated we can plan a Windows port too, if some future team member is not used to Linux.
We can also try to contact AP to request an RSS feed for new APKs on APKMirror.
Click to expand...
Click to collapse
I've been using Cygwin on Windows and the scripts work great.
Have you ever wanted to flash the Cyanogen Apps package, only to find that you didn't want all of the apps that were included? Perhaps you like your dialer app, or you don't trust the TrueCaller integration. Maybe you want the Theme Store, but not the new Gallery. Maybe you just want to get rid of CyanogenStats and CMLogger because you're paranoid. Whatever the case, I've got the tool for you!
*Canned Applause*
Behold, I give you this, the program I put together because I wanted to do exactly that: modify the C-Apps package. Just run the program. It downloads the package for you, unpacks it, modifies it, repacks it, and places it in your user's home directory for use.
This program comes with no warranty, implied or otherwise, so on and so forth. I am not responsible for broken things. Use at your own peril.
Beware: This version does not check for inter-app dependencies, so if keeping the new Dialer but the old InCallUI breaks your phone, that's on you. Make sure you know what you are doing as far as that goes. This tool merely helps you.
I have tested this program as best as I can and everything seems to be working correctly. Still, things happen and I can't test for every case. If something bad happens, let me know either here or, more preferably, in the GitHub Issues.
To run this program, make sure you have Java installed and open Command Prompt or a Terminal Emulator and navigate to the directory where the .jar file is located. For those who don't know, this involves using the `cd` command to change directories and `dir` (Windows) or `ls` (Mac/Linux) to list files in the current directory. Then run the file with the command:
Code:
java -jar ModCApps.jar
Other note: I have read through the Cyanogen Terms of Use and do not believe that this project violates them in any way. If I am wrong, let me know and I will take this down. I make no profit from the project, save any thanks people may give me.
Downloads:
Releases on GitHub
XDA:DevDB Information
ModCApps, Tool/Utility for all devices (see above for details)
Contributors
Shadow53
Source Code: https://github.com/Shadow53/ModCApps
Version Information
Status: Beta
Current Beta Version: 0.1.0
Beta Release Date: 2016-05-05
Created 2016-05-06
Last Updated 2016-05-06
Reserved
Reserved
Samsung Galaxy Grand Duos Oreo Kernel Source
download link-> bottom of the thread.
Linux kernel release 3.x <http://kernel.org/>
These are the release notes for Linux version 3. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong!!
WHAT IS LINUX?
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
It is distributed under the GNU General Public License - see the
accompanying COPYING file for more details.
ON WHAT HARDWARE DOES IT RUN?
Although originally developed first for 32-bit x86-based PCs (386 or higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.
Linux is easily portable to most general-purpose 32- or 64-bit architectures
as long as they have a paged memory management unit (PMMU) and a port of the
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
also been ported to a number of architectures without a PMMU, although
functionality is then obviously somewhat limited.
Linux has also been ported to itself. You can now run the kernel as a
userspace application - this is called UserMode Linux (UML).
DOCUMENTATION:
- There is a lot of documentation available both in electronic form on
the Internet and in books, both Linux-specific and pertaining to
general UNIX questions. I'd recommend looking into the documentation
subdirectories on any Linux FTP site for the LDP (Linux Documentation
Project) books. This README is not meant to be documentation on the
system: there are much better sources available.
- There are various README files in the Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. See Documentation/00-INDEX for a list of what
is contained in each file. Please read the Changes file, as it
contains information about the problems, which may result by upgrading
your kernel.
- The Documentation/DocBook/ subdirectory contains several guides for
kernel developers and users. These guides can be rendered in a
number of formats: PostScript (.ps), PDF, HTML, & man-pages, among others.
After installation, "make psdocs", "make pdfdocs", "make htmldocs",
or "make mandocs" will render the documentation in the requested format.
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:
gzip -cd linux-3.X.tar.gz | tar xvf -
or
bzip2 -dc linux-3.X.tar.bz2 | tar xvf -
Replace "XX" with the version number of the latest kernel.
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
- You can also upgrade between 3.x releases by patching. Patches are
distributed in the traditional gzip and the newer bzip2 format. To
install by patching, get all the newer patch files, enter the
top level directory of the kernel source (linux-3.x) and execute:
gzip -cd ../patch-3.x.gz | patch -p1
or
bzip2 -dc ../patch-3.x.bz2 | patch -p1
(repeat xx for all versions bigger than the version of your current
source tree, _in_order_) and you should be ok. You may want to remove
the backup files (xxx~ or xxx.orig), and make sure that there are no
failed patches (xxx# or xxx.rej). If there are, either you or me has
made a mistake.
Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 3.x kernel. Please read
Documentation/applying-patches.txt for more information.
Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found.
linux/scripts/patch-kernel linux
The first argument in the command above is the location of the
kernel source. Patches are applied from the current directory, but
an alternative directory can be specified as the second argument.
- If you are upgrading between releases using the stable series patches
(for example, patch-3.x.y), note that these "dot-releases" are
not incremental and must be applied to the 3.x base tree. For
example, if your base kernel is 3.0 and you want to apply the
3.0.3 patch, you do not and indeed must not first apply the
3.0.1 and 3.0.2 patches. Similarly, if you are running kernel
version 3.0.2 and want to jump to 3.0.3, you must first
reverse the 3.0.2 patch (that is, patch -R) _before_ applying
the 3.0.3 patch.
You can read more on this in Documentation/applying-patches.txt
- Make sure you have no stale .o files and dependencies lying around:
cd linux
make mrproper
You should now have the sources correctly installed.
SOFTWARE REQUIREMENTS
Compiling and running the 3.x kernels requires up-to-date
versions of various software packages. Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages. Beware that using
excessively old versions of these packages can cause indirect
errors that are very difficult to track down, so don't assume that
you can just update packages when obvious problems arise during
build or operation.
BUILD directory for the kernel:
When compiling the kernel all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
place for the output files (including .config).
Example:
kernel source code: /usr/src/linux-3.N
build directory: /home/name/build/kernel
To configure and build the kernel use:
cd /usr/src/linux-3.N
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
Please note: If the 'O=output/dir' option is used then it must be
used for all invocations of make.
CONFIGURING the kernel:
Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use "make oldconfig", which will
only ask you for the answers to new questions.
- Alternate configuration commands are:
"make config" Plain text interface.
"make menuconfig" Text based color menus, radiolists & dialogs.
"make nconfig" Enhanced text based color menus.
"make xconfig" X windows (Qt) based configuration tool.
"make gconfig" X windows (Gtk) based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
new config symbols.
"make silentoldconfig"
Like above, but avoids cluttering the screen
with questions already answered.
Additionally updates the dependencies.
"make defconfig" Create a ./.config file by using the default
symbol values from either arch/$ARCH/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.
"make ${PLATFORM}_defconfig"
Create a ./.config file by using the default
symbol values from
arch/$ARCH/configs/${PLATFORM}_defconfig.
Use "make help" to get a list of all available
platforms of your architecture.
"make allyesconfig"
Create a ./.config file by setting symbol
values to 'y' as much as possible.
"make allmodconfig"
Create a ./.config file by setting symbol
values to 'm' as much as possible.
"make allnoconfig" Create a ./.config file by setting symbol
values to 'n' as much as possible.
"make randconfig" Create a ./.config file by setting symbol
values to random values.
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
under some circumstances lead to problems: probing for a
nonexistent controller card may confuse your other controllers
- compiling the kernel with "Processor type" set higher than 386
will result in a kernel that does NOT work on a 386. The
kernel will detect this on bootup, and give up.
- A kernel with math-emulation compiled in will still use the
coprocessor if one is present: the math emulation will just
never get used in that case. The kernel will be slightly larger,
but will work on different machines regardless of whether they
have a math coprocessor or not.
- the "kernel hacking" configuration details usually result in a
bigger or slower kernel (or both), and can even make the kernel
less stable by configuring some routines to actively try to
break bad code to find kernel problems (kmalloc()). Thus you
should probably answer 'n' to the questions for
"development", "experimental", or "debugging" features.
COMPILING the kernel:
- Make sure you have at least gcc 3.2 available.
For more information, refer to Documentation/Changes.
Please note that you can still run a.out user programs with this kernel.
- Do a "make" to create a compressed kernel image. It is also
possible to do "make install" if you have lilo installed to suit the
kernel makefiles, but you may want to check your particular lilo setup first.
To do the actual install you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
- If you configured any of the parts of the kernel as `modules', you
will also have to do "make modules_install".
- Verbose kernel compile/build output:
Normally the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
For this, use "verbose" build mode. This is done by inserting
"V=1" in the "make" command. E.g.:
make V=1 all
To have the build system also tell the reason for the rebuild of each
target, use "V=2". The default is "V=0".
- Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a "make modules_install".
Alternatively, before compiling, use the kernel config option
"LOCALVERSION" to append a unique suffix to the regular kernel version.
LOCALVERSION can be set in the "General Setup" menu.
- In order to boot your new kernel, you'll need to copy the kernel
image (e.g. .../linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- Booting a kernel directly from a floppy without the assistance of a
bootloader such as LILO, is no longer supported.
If you boot Linux from the hard drive, chances are you use LILO which
uses the kernel image as specified in the file /etc/lilo.conf. The
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
You may wish to edit /etc/lilo.conf to specify an entry for your
old kernel image (say, /vmlinux.old) in case the new one does not
work. See the LILO docs for more information.
After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
If you ever need to change the default root device, video mode,
ramdisk size, etc. in the kernel image, use the 'rdev' program (or
alternatively the LILO boot options when appropriate). No need to
recompile the kernel to change these parameters.
- Reboot with the new kernel and enjoy.
IF SOMETHING GOES WRONG:
- If you have problems that seem to be due to kernel bugs, please check
the file MAINTAINERS to see if there is a particular person associated
with the part of the kernel that you are having trouble with. If there
isn't anyone listed there, then the second best thing is to mail
them to me ([email protected]), and possibly to any other
relevant mailing-list or to the newsgroup.
- In all bug-reports, *please* tell what kernel you are talking about,
how to duplicate the problem, and what your setup is (use your common
sense). If the problem is new, tell me so, and if the problem is
old, please try to tell me when you first noticed it.
- If the bug results in a message like
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
or similar kernel debugging information on your screen or in your
system log, please duplicate it *exactly*. The dump may look
incomprehensible to you, but it does contain information that may
help debugging the problem. The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example it's due to a bad kernel pointer). More information
on making sense of the dump is in Documentation/oops-tracing.txt
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the "ksymoops" program to make
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
This utility can be downloaded from
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ .
Alternately you can do the dump lookup by hand:
- In debugging dumps like the above, it helps enormously if you can
look up what the EIP value means. The hex value as such doesn't help
me or anybody else very much: it will depend on your particular
kernel setup. What you should do is take the hex value from the EIP
line (ignore the "0010:"), and look it up in the kernel namelist to
see which kernel function contains the offending address.
To find out the kernel function name, you'll need to find the system
binary associated with the kernel that exhibited the symptom. This is
the file 'linux/vmlinux'. To extract the namelist and match it against
the EIP from the kernel crash, do:
nm vmlinux | sort | less
This will give you a list of kernel addresses sorted in ascending
order, from which it is simple to find the function that contains the
offending address. Note that the address given by the kernel
debugging messages will not necessarily match exactly with the
function addresses (in fact, that is very unlikely), so you can't
just 'grep' the list: the list will, however, give you the starting
point of each kernel function, so by looking for the function that
has a starting address lower than the one you are searching for but
is followed by a function with a higher address you will find the one
you want. In fact, it may be a good idea to include a bit of
"context" in your problem report, giving a few lines around the
interesting one.
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the REPORTING-BUGS document for details.
- Alternately, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
clean". You'll also need to enable CONFIG_PROC_FS (via "make config").
After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore".
You can now use all the usual gdb commands. The command to look up the
point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes
with the EIP value.)
gdb'ing a non-running kernel currently fails because gdb (wrongly)
disregards the starting offset for which the kernel is compiled.
Download.
OREO KERNEL SOURCE 3.x
credits:-
@osas514
@GHsR
vasanth36 said:
Samsung Galaxy Grand Duos Oreo Kernel Source
download link-> bottom of the thread.
Linux kernel release 3.x <http://kernel.org/>
These are the release notes for Linux version 3. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong!!
WHAT IS LINUX?
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
It is distributed under the GNU General Public License - see the
accompanying COPYING file for more details.
ON WHAT HARDWARE DOES IT RUN?
Although originally developed first for 32-bit x86-based PCs (386 or higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.
Linux is easily portable to most general-purpose 32- or 64-bit architectures
as long as they have a paged memory management unit (PMMU) and a port of the
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
also been ported to a number of architectures without a PMMU, although
functionality is then obviously somewhat limited.
Linux has also been ported to itself. You can now run the kernel as a
userspace application - this is called UserMode Linux (UML).
DOCUMENTATION:
- There is a lot of documentation available both in electronic form on
the Internet and in books, both Linux-specific and pertaining to
general UNIX questions. I'd recommend looking into the documentation
subdirectories on any Linux FTP site for the LDP (Linux Documentation
Project) books. This README is not meant to be documentation on the
system: there are much better sources available.
- There are various README files in the Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. See Documentation/00-INDEX for a list of what
is contained in each file. Please read the Changes file, as it
contains information about the problems, which may result by upgrading
your kernel.
- The Documentation/DocBook/ subdirectory contains several guides for
kernel developers and users. These guides can be rendered in a
number of formats: PostScript (.ps), PDF, HTML, & man-pages, among others.
After installation, "make psdocs", "make pdfdocs", "make htmldocs",
or "make mandocs" will render the documentation in the requested format.
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:
gzip -cd linux-3.X.tar.gz | tar xvf -
or
bzip2 -dc linux-3.X.tar.bz2 | tar xvf -
Replace "XX" with the version number of the latest kernel.
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
- You can also upgrade between 3.x releases by patching. Patches are
distributed in the traditional gzip and the newer bzip2 format. To
install by patching, get all the newer patch files, enter the
top level directory of the kernel source (linux-3.x) and execute:
gzip -cd ../patch-3.x.gz | patch -p1
or
bzip2 -dc ../patch-3.x.bz2 | patch -p1
(repeat xx for all versions bigger than the version of your current
source tree, _in_order_) and you should be ok. You may want to remove
the backup files (xxx~ or xxx.orig), and make sure that there are no
failed patches (xxx# or xxx.rej). If there are, either you or me has
made a mistake.
Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 3.x kernel. Please read
Documentation/applying-patches.txt for more information.
Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found.
linux/scripts/patch-kernel linux
The first argument in the command above is the location of the
kernel source. Patches are applied from the current directory, but
an alternative directory can be specified as the second argument.
- If you are upgrading between releases using the stable series patches
(for example, patch-3.x.y), note that these "dot-releases" are
not incremental and must be applied to the 3.x base tree. For
example, if your base kernel is 3.0 and you want to apply the
3.0.3 patch, you do not and indeed must not first apply the
3.0.1 and 3.0.2 patches. Similarly, if you are running kernel
version 3.0.2 and want to jump to 3.0.3, you must first
reverse the 3.0.2 patch (that is, patch -R) _before_ applying
the 3.0.3 patch.
You can read more on this in Documentation/applying-patches.txt
- Make sure you have no stale .o files and dependencies lying around:
cd linux
make mrproper
You should now have the sources correctly installed.
SOFTWARE REQUIREMENTS
Compiling and running the 3.x kernels requires up-to-date
versions of various software packages. Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages. Beware that using
excessively old versions of these packages can cause indirect
errors that are very difficult to track down, so don't assume that
you can just update packages when obvious problems arise during
build or operation.
BUILD directory for the kernel:
When compiling the kernel all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
place for the output files (including .config).
Example:
kernel source code: /usr/src/linux-3.N
build directory: /home/name/build/kernel
To configure and build the kernel use:
cd /usr/src/linux-3.N
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
Please note: If the 'O=output/dir' option is used then it must be
used for all invocations of make.
CONFIGURING the kernel:
Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use "make oldconfig", which will
only ask you for the answers to new questions.
- Alternate configuration commands are:
"make config" Plain text interface.
"make menuconfig" Text based color menus, radiolists & dialogs.
"make nconfig" Enhanced text based color menus.
"make xconfig" X windows (Qt) based configuration tool.
"make gconfig" X windows (Gtk) based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
new config symbols.
"make silentoldconfig"
Like above, but avoids cluttering the screen
with questions already answered.
Additionally updates the dependencies.
"make defconfig" Create a ./.config file by using the default
symbol values from either arch/$ARCH/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.
"make ${PLATFORM}_defconfig"
Create a ./.config file by using the default
symbol values from
arch/$ARCH/configs/${PLATFORM}_defconfig.
Use "make help" to get a list of all available
platforms of your architecture.
"make allyesconfig"
Create a ./.config file by setting symbol
values to 'y' as much as possible.
"make allmodconfig"
Create a ./.config file by setting symbol
values to 'm' as much as possible.
"make allnoconfig" Create a ./.config file by setting symbol
values to 'n' as much as possible.
"make randconfig" Create a ./.config file by setting symbol
values to random values.
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
under some circumstances lead to problems: probing for a
nonexistent controller card may confuse your other controllers
- compiling the kernel with "Processor type" set higher than 386
will result in a kernel that does NOT work on a 386. The
kernel will detect this on bootup, and give up.
- A kernel with math-emulation compiled in will still use the
coprocessor if one is present: the math emulation will just
never get used in that case. The kernel will be slightly larger,
but will work on different machines regardless of whether they
have a math coprocessor or not.
- the "kernel hacking" configuration details usually result in a
bigger or slower kernel (or both), and can even make the kernel
less stable by configuring some routines to actively try to
break bad code to find kernel problems (kmalloc()). Thus you
should probably answer 'n' to the questions for
"development", "experimental", or "debugging" features.
COMPILING the kernel:
- Make sure you have at least gcc 3.2 available.
For more information, refer to Documentation/Changes.
Please note that you can still run a.out user programs with this kernel.
- Do a "make" to create a compressed kernel image. It is also
possible to do "make install" if you have lilo installed to suit the
kernel makefiles, but you may want to check your particular lilo setup first.
To do the actual install you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
- If you configured any of the parts of the kernel as `modules', you
will also have to do "make modules_install".
- Verbose kernel compile/build output:
Normally the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
For this, use "verbose" build mode. This is done by inserting
"V=1" in the "make" command. E.g.:
make V=1 all
To have the build system also tell the reason for the rebuild of each
target, use "V=2". The default is "V=0".
- Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a "make modules_install".
Alternatively, before compiling, use the kernel config option
"LOCALVERSION" to append a unique suffix to the regular kernel version.
LOCALVERSION can be set in the "General Setup" menu.
- In order to boot your new kernel, you'll need to copy the kernel
image (e.g. .../linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- Booting a kernel directly from a floppy without the assistance of a
bootloader such as LILO, is no longer supported.
If you boot Linux from the hard drive, chances are you use LILO which
uses the kernel image as specified in the file /etc/lilo.conf. The
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
You may wish to edit /etc/lilo.conf to specify an entry for your
old kernel image (say, /vmlinux.old) in case the new one does not
work. See the LILO docs for more information.
After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
If you ever need to change the default root device, video mode,
ramdisk size, etc. in the kernel image, use the 'rdev' program (or
alternatively the LILO boot options when appropriate). No need to
recompile the kernel to change these parameters.
- Reboot with the new kernel and enjoy.
IF SOMETHING GOES WRONG:
- If you have problems that seem to be due to kernel bugs, please check
the file MAINTAINERS to see if there is a particular person associated
with the part of the kernel that you are having trouble with. If there
isn't anyone listed there, then the second best thing is to mail
them to me ([email protected]), and possibly to any other
relevant mailing-list or to the newsgroup.
- In all bug-reports, *please* tell what kernel you are talking about,
how to duplicate the problem, and what your setup is (use your common
sense). If the problem is new, tell me so, and if the problem is
old, please try to tell me when you first noticed it.
- If the bug results in a message like
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
or similar kernel debugging information on your screen or in your
system log, please duplicate it *exactly*. The dump may look
incomprehensible to you, but it does contain information that may
help debugging the problem. The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example it's due to a bad kernel pointer). More information
on making sense of the dump is in Documentation/oops-tracing.txt
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the "ksymoops" program to make
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
This utility can be downloaded from
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ .
Alternately you can do the dump lookup by hand:
- In debugging dumps like the above, it helps enormously if you can
look up what the EIP value means. The hex value as such doesn't help
me or anybody else very much: it will depend on your particular
kernel setup. What you should do is take the hex value from the EIP
line (ignore the "0010:"), and look it up in the kernel namelist to
see which kernel function contains the offending address.
To find out the kernel function name, you'll need to find the system
binary associated with the kernel that exhibited the symptom. This is
the file 'linux/vmlinux'. To extract the namelist and match it against
the EIP from the kernel crash, do:
nm vmlinux | sort | less
This will give you a list of kernel addresses sorted in ascending
order, from which it is simple to find the function that contains the
offending address. Note that the address given by the kernel
debugging messages will not necessarily match exactly with the
function addresses (in fact, that is very unlikely), so you can't
just 'grep' the list: the list will, however, give you the starting
point of each kernel function, so by looking for the function that
has a starting address lower than the one you are searching for but
is followed by a function with a higher address you will find the one
you want. In fact, it may be a good idea to include a bit of
"context" in your problem report, giving a few lines around the
interesting one.
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the REPORTING-BUGS document for details.
- Alternately, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
clean". You'll also need to enable CONFIG_PROC_FS (via "make config").
After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore".
You can now use all the usual gdb commands. The command to look up the
point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes
with the EIP value.)
gdb'ing a non-running kernel currently fails because gdb (wrongly)
disregards the starting offset for which the kernel is compiled.
Download.
OREO KERNEL SOURCE 3.x
credits:-
@osas514
@GHsR
Click to expand...
Click to collapse
How is it going to help us?
Repo deleted