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.
Related
This project is no longer being updated. Feel free to use the code.
Android Builder (AB v.5)
kiel123 has joined the AB team!
Thanks to dsixda, Armin Coralic, and cteneyck. I do have permission to reuse their code.
Requirements:
Ubuntu Linux or variant
dsixda's HTC Android Basic Kitchen - http://forum.xda-developers.com/showthread.php?t=633246
In my crazy quest to learn more about Android, I decided to create a companion to dsixda's kitchen that will take some of the drudgery out of downloading and compiling AOSP and the HTC kernel.
Here's what the current menus looks like:
Code:
Select the device that you would like to build for.
1) HTC Droid Eris
a) About Builder
0. Exit
Please enter option number:
and then
Code:
1. Sync AOSP - Cupcake (1.5) repo
2. Sync AOSP - Donut (1.6) repo
3. Sync AOSP - Eclair (2.1) repo
4. Sync AOSP - Froyo (2.2) repo
0. Exit
Please enter option number:
You can follow these two steps, and you will get a freshly compiled, but unsigned ROM in the original_update folder. After running it through the kitchen, it boots up just fine. Of course, most of the hardware doesn't work. That's the part that I am working on now (seriously, I am). I've been working on this for a while, because as I said - this is really about me learning. If I can make a tool that someone finds useful, then great!
Install instructions:
1) download and unzip dsixda's kitchen to whatever directory you want
2) download Android Builder into kitchen's scripts/plugins folder and unzip
3) back out and start the kitchen
4) select 'Run plugin scripts' from Advanced menu and select 'Android Builder'
5) you're there!
NOTE: This will try to install/update all of the packages that it needs, including Java5. Please look at the code so that you know what it's doing. That's just a good general practice with any code that you can actually look at and that you have to run as root...
Future plans:
1) add more kernels (devices)
2) add more vendor trees (goes along with devices)
3) add more repos (CM5, CM6, AOSP Master)
I hope someone finds this useful, and feel free to post useful suggestions/bug reports.
DOWNLOAD - (https://github.com/gnarlyc/android_builder)
CHANGELOG -
v5. - kiel123 re-wrote v.4 as a plugin to dsixda's kitchen with me testing afterward, minor fixes, removed Java6 as no longer needed by kitchen
v.4 - re-wrote to add structure to support more devices in the future
added option for Cupcake, Donut, and Froyo
added .config files that enable touchscreen in kernel by default
v.3 - unreleased build
v.2 - corrected misspellings in code and dialogs
added sudo to launch setup script (Still need to sudo bash first. Sorry.)
v.1 - initial release
Very nice. I have been doing the same. I have used darchstar's post here as the basis of my work. But, I am always glad to look how others are doing things. Thanks for the post.
arockj said:
Very nice. I have been doing the same. I have used darchstar's post here as the basis of my work. But, I am always glad to look how others are doing things. Thanks for the post.
Click to expand...
Click to collapse
Thanks for the thanks! I don't quite get the vendor tree thing, but I just need to look at it again a few times. And, that's where I'm at. It would be really neat to be able create a working AOSP ROM from scratch with minimal manual intervention. It might not be possible, but I haven't found that out yet. (But wait! If you can do it manually, it can be scripted. Right?)
there's typo in your install script
look for line: android_builder*
should be android-builder*
and your install script should use mv command instead of cp to avoid files duplication
EDIT: also you should use sudo command along with ./ab_setup script or include within script as well.
When i ran ./abmenu and i get this message
Code:
Please copy 'menu-kd' to the root of your kitchen folder with 'menu'
menu-kd?.... don't you mean abmenu? turned out it was looking for menu file which i had it renamed to kitchen_menu but I fixed that on my part and all is working well.
Dont let any of my criticism scare you away, I can see there's a lot of potential use for this scripts, great start by the way.
firestrife23 said:
there's typo in your install script
look for line: android_builder*
should be android-builder*
and your install script should use mv command instead of cp to avoid files duplication
EDIT: also you should use sudo command along with ./ab_setup script or include within script as well.
When i ran ./abmenu and i get this message
Code:
Please copy 'menu-kd' to the root of your kitchen folder with 'menu'
menu-kd?.... don't you mean abmenu? turned out it was looking for menu file which i had it renamed to kitchen_menu but I fixed that on my part and all is working well.
Dont let any of my criticism scare you away, I can see there's a lot of potential use for this scripts, great start by the way.
Click to expand...
Click to collapse
I renamed all of the scripts at the last minute and thought that I had them fixed. I'll make the corrections and repost. The goal is to get this thing working well. Your criticism is just more motivation. Thanks!
I'm new to all this but I would love this to work with Froyo source.
Geo411m said:
I'm new to all this but I would love this to work with Froyo source.
Click to expand...
Click to collapse
The current 'internal' build works with Cupcake (1.5), Eclair (2.1), and Froyo (2.2). It's not ready to release though. Give me another week or two. I'm working on proprietary bits now, so that you get a more usable ROM from the start.
Although from your sig, it appears that you don't have an Eris, so you probably don't care much about it's proprietary bits. If you want it to get Froyo instead of Eclair, you can just change 'eclair' to 'froyo' in the script that creates the repo.
I'm with you on Froyo. I have a feeling in a month or two very few people will want to run a pre-Froyo ROM. It's really nice.
rm error on install
i keep getting "rm: cannot remove './bkup': No such file or directory"
the file is there untill i run the ./install script then it disappears and shoots me an error any help would be appriciated
Sjflowerhorn said:
i keep getting "rm: cannot remove './bkup': No such file or directory"
the file is there untill i run the ./install script then it disappears and shoots me an error any help would be appriciated
Click to expand...
Click to collapse
That files was used by me while developing the code. It's not needed. I'll fix the install script for v.5, but if you really want to fix the script now... Just remove the line -
'rm ./bkup'
from the 'install' script
You should still be able to start Android Builder by typing './abmenu', as long as it's in the same folder with the kitchen's menu. The error shouldn't matter.
gnarlyc said:
That files was used by me while developing the code. It's not needed. I'll fix the install script for v.5, but if you really want to fix the script now... Just remove the line -
'rm ./bkup'
from the 'install' script
You should still be able to start Android Builder by typing './abmenu', as long as it's in the same folder with the kitchen's menu. The error shouldn't matter.
Click to expand...
Click to collapse
k thanks i think it worked the same even with the error but got it =)
Sjflowerhorn said:
k thanks i think it worked the same even with the error but got it =)
Click to expand...
Click to collapse
Good deal. Let me know how it goes.
gnarlyc --
Have you thought of making this into a .plugin file that can be placed in the scripts/plugins folder of the HTC Android Kitchen? Then that way you won't need to update your scripts each time I update my kitchen
In my thread I could provide a link to your tool, so that people can add that plugin if they want.
dsixda said:
gnarlyc --
Have you thought of making this into a .plugin file that can be placed in the scripts/plugins folder of the HTC Android Kitchen? Then that way you won't need to update your scripts each time I update my kitchen
In my thread I could provide a link to your tool, so that people can add that plugin if they want.
Click to expand...
Click to collapse
The thought has occurred to me.
Give me a bit. A link in your thread would be great. It might even motivate me to add more devices. Getting stuck on adding Eris proprietary bits has lead me down the road of making a ROM (http://forum.xda-developers.com/showthread.php?t=725447) and documenting the process. I'll get back to Android Builder soon though.
Ok, so...
TO-DO
-------
1) rewrite AB as a plugin to dsixda's HTC Android Kitchen
2) add proprietary bits for Eris
3) add more devices
4) add CM repos
5) add Gingerbread repo
6) add compatibility with more distros
i am getting line 28: update-java-alernatives: command not found?
lord194409 said:
i am getting line 28: update-java-alernatives: command not found?
Click to expand...
Click to collapse
Interesting... I've tested from a freshly installed Ubuntu installation several times. It should install everything you need.
You could try 'update-alternatives --config java' and let me know what it says. You could also look for a file called 'setup_ran' in the root of the Kitchen, and delete it. Start './abmenu' after that and try again.
thanks for answering. Could the problem be that i installed it on cygwin.
lord194409 said:
thanks for answering. Could the problem be that i installed it on cygwin.
Click to expand...
Click to collapse
Yes. Android Builder will not work under cygwin. I don't know that it ever will. That's on the TO-DO list, but it's so far down that it's not on the posted TO-DO list.
I've only tested under Xubuntu 10.04 and minimal Ubuntu 10.04.
If you happen to work it out on cygwin, let me know! I'm sure others would be happy to have the option. Heck, I might even be. I'm mainly using Ubuntu because of AB anyway. (Although, it is kind of growing on me.)
thanks i will look in to it.
Sent from my Eris using XDA App
just wanted to let you know that it didn't work for me. It runs, gives some errors and outputs a update.zip called AOSPbase but the file is only 1.1kb in size.
Geo411m said:
just wanted to let you know that it didn't work for me. It runs, gives some errors and outputs a update.zip called AOSPbase but the file is only 1.1kb in size.
Click to expand...
Click to collapse
make sure you have java5 and java6 jre/jdk installed. it should work then. i had a similar issue the first time through... took it literally 10hours plus, then output was the 1.1k AOSPBase.zip file.
manually installed all java components, and everything worked perfectly then (and took half the time)
This could be considered part of the development forum or the apps and theme forum depending on how you look at it. if you have an issue, just click the report button and request that it be moved. no need to flame and troll and post that you reported it, just do it and move on.
Lots of people have asked me how to put together a theme control file, and its actually VERY easy but this tool makes it even easier.
this is an example of a theme control file created by this tool
Test-Theme.xml
Code:
<themename>Test-theme</themename>
<author>tater-salad</author>
<phone>Android Phone Codename Hulk</phone>
<rom>CM 8</rom>
<item>Phone.apk</item>
<path>/system/app<path>
<item>framework-res.apk</item>
<path>/system/framework</path>
<description>Requires reboot</description>
<item>FM-Reciever.apk</item>
<path>/data/app<path>
<item>My-custom-app.apk</item>
<path>/data/app<path>
run the mm-builder script and follow the on screen directions. you will of course need to put the correct replacement files in their respective directories, but this script will make all the right folders and set up your theme.xml for you. Bash scrip means linux only. This is also a super easy script, so i may get a batch version soon.
You can extract this file to any directory
All thanks to Stericson. W/O him we wouldnt have a metamorph app to begin with
######################################################################################################
v2
includes these additions
Code:
mkdir $app
mkdir $app/res
mkdir $app/res/drawable
mkdir $app/res/drawable-mdpi
mkdir $app/res/drawable-land-mdpi
mkdir $app/res/drawable-port-mdpi
these are the commonly used directories when it comes to theming. now all the sub-folders should be set up right.
I think this tool will be very helpful for newer themers and the like, looking forward to a windows adaptation.
also, what does it matter if ban_dover was andrizoid, seems to me hes not doing any harm here now, just trying to help people out, so give a guy a chance to rectify himself before you all start the flamethrowers
snyluc13 said:
I think this tool will be very helpful for newer themers and the like, looking forward to a windows adaptation.
also, what does it matter if ban_dover was andrizoid, seems to me hes not doing any harm here now, just trying to help people out, so give a guy a chance to rectify himself before you all start the flamethrowers
Click to expand...
Click to collapse
windows version is certainly viable, but batch is SO alien coming from bash. there isnt even an ls command
im going to have to play around and get a feel for batch before i get to work on it.
v3 is up. ive put together working metamorph themes using v3, so its been pretty well tested.
How about some constructive use of this thread?
ban_dover,
I've got a question. I read through Stericson's announcement post on XDA, and also the project page, and he mentions limitations due to signing checks of market apps.
Does it actually re-sign the .apk with the test key that all the devs use, or does it merely re-zip the .apk so that the manifest and keys are broken (won't pass a jarsigner -verify test)?
If it is the 2nd alternative, I guess that would means that Android does not check "non-market app" installs for valid signatures? Or that it doesn't check system apps but does check market apps?
The reason this piques my interest is that I noticed one of the devs recently released a ROM which had all its apps de-odexed and re-signed with the test key. (Can't remember which ROM, perhaps an xtr* ROM?)
Anyone else that knows how this goes is welcome to answer as well.
bftb0
Im going to lock this thread if the flame war doesn't stop
Play nice
Edit: Thread re-opened, ban_dover and I discussed and hopefully we will not have any more issues.
Thanks
Captainkrtek
bftb0 said:
How about some constructive use of this thread?
ban_dover,
I've got a question. I read through Stericson's announcement post on XDA, and also the project page, and he mentions limitations due to signing checks of market apps.
Does it actually re-sign the .apk with the test key that all the devs use, or does it merely re-zip the .apk so that the manifest and keys are broken (won't pass a jarsigner -verify test)?
If it is the 2nd alternative, I guess that would means that Android does not check "non-market app" installs for valid signatures? Or that it doesn't check system apps but does check market apps?
The reason this piques my interest is that I noticed one of the devs recently released a ROM which had all its apps de-odexed and re-signed with the test key. (Can't remember which ROM, perhaps an xtr* ROM?)
Anyone else that knows how this goes is welcome to answer as well.
bftb0
Click to expand...
Click to collapse
to be honest im not sure. but i can say that the rom your talking about isnt going to have any issues with anything because of the re-signing.
so the those who have downloaded it, what do you think?
ive tested it by putting together a few simple MMs, and it worked fne for me. have any of you ran into any issues?
A bit surprised that I haven't seen this mentioned on XDA yet...
Stephen (Stericson,) Adam Shanks (ChainsDD) and I have been working on this new library for a few days.
You can find more about it here: http://code.google.com/p/roottools/
Several other people have already enrolled as committers so I expect to see even more activity shortly.
In a nutshell, this library currently:
checks whether you have root access
checks whether BusyBox is installed
Helps you install BusyBox if necessary
Runs series of arbitrary shell commands as root
Checks partition space
Mount/unmount partitions
Installs binaries created from C/C++ for you
Anyone who wishes to pitch in is welcome!
very cool, thanks
Very interesting, i will keep an eye on that
Interesting. Seen a couple things I could have done better in my own attempts. So for me it seems like a good reference for future projects.
One question though: in the installBinary() function you are creating a bogus file in order to get the /files directory created. may I ask if there's a particular reason why you're not just doing a mkdir?
Creation of files/ is delegated to the Android SDK itself; this way, we avoid as much as possible assuming the location of that directory.
I know we do not avoid it completely (when we need to invoke the newly created binary, for instance) but I have hope that in the future we can figure that one out as well.
Just Uploaded version 1.4
http://code.google.com/p/roottools/...ols-1.4-sdk3-generic.jar&can=2&q=#makechanges
Although the library has grown a lot since this post was made and now can handle a lot more for the developer.
Please compile the latest version 4.4.
I put this here because I have only tested with my s5, and its not done yet so wanted a general topic for feedback before putting in a dev section. But please feel free to move this as you see fit moderators.
While playing with making the hotspot mod and other general investigation into things on my s5, it dawned on me that its kind of a PITA to keep things organized. Kitchens do a pretty good job at helping to give you a method to the madness when making ROMs but I haven't found anything too helpful for making mods. So that gave me an idea, I have decided to call it modStudio for now, a place to keep needed tools and a workflow to keep things organized and not chaotic.
This project is far from complete but I think its in a good place now and was hoping to possibly get a little feedback.
I am running on a 64 bit linux machine, and right now that is all that is supported. If you are already building things for android chances are you have a machine like this around already anyway.
I don't have a full tutorial written up, and I would rather spend time adding functionality for now but you can pull down the latest copy by doing:
Code:
git clone https://github.com/miked63017/modStudio.git
There are some examples in the readme, but basically go into the directory that the repo created and source the toolbox file
Code:
source tools/toolbox
This sets up a few commands that I find useful, and hopefully you will too
I will paste what I have in the readme for now, and work on the tutorial as functionality is added, please let me know what you guys think. Any comments, suggestions, requests or contributions are welcome.
In the README.md:
This is a tool I made to aid in the process of making mods for Android phones.
I was tired of having multiple tools in different places and wanted to bring everything together with some easy shortcuts.
This should work on any 64 bit linux distro at the moment, but I have only tested on OpenSuse 13.1 since that is what I use.
Things that are assumed:
you are running on linux 64 bit
you have adb correctly setup and in your $PATH
you have aapt and java setup and in your $PATH
you know how to make changes once you have a decompiled apk
A few commands require you to have your phone plugged in, plug it in.
Some general notes for now:
You must always generate a source directory from which files will be used to modify
The source directory always stays untouched, so if you want to start over you can clean your playground and begin again
If you deodex an apk or ar that does not have a .odex it will be basically the same thing as the playWith command
If you have a source dir populated from your phone decompiling will take a while to search for framework files, unless you trim your source dir down
Example usage:
Code:
#setup modStudio, only need to do once
git clone [url]https://github.com/miked63017/modStudio.git[/url]
cd modStudio
#Need to source this file in your shell everytime you want to use modStudio
. tools/toolbox
#Basic workflow working with a stock odexed system image, must be rooted and have busybox installed
#example given for services.jar but should work with any
cleanSource
cleanPlayGround
pullSystemFromPhone
deodex services.jar
decompile services.jar
#make your changes in playground/system/framework/services.jar.out
build services.jar
odex services.jar
installFromPlayground
#Workflow from zip file, assuming already deodexed ROM
cleanSource
cleanPlayGround
pullSystemFromROM romname.zip
playWith services.jar
decompile services.jar
#make your changes in playground/system/framework/services.jar.out
build services.jar
installFromPlayground
Very nice will check this out when I get some time. Great work this could prove very helpful to the devs.
Sent from my SM-G900P using Tapatalk
vinman12 said:
Very nice will check this out when I get some time. Great work this could prove very helpful to the devs.
Sent from my SM-G900P using Tapatalk
Click to expand...
Click to collapse
Made a few updates, if anybody is testing please do git pull often
Sent from my SM-G900P using XDA Free mobile app
Wicked cool! I assume the re-odex happens right on the phone? I need to get a VM setup so I can play with it..
Sent from my SPH-L710 using Tapatalk
rocket321 said:
Wicked cool! I assume the re-odex happens right on the phone? I need to get a VM setup so I can play with it..
Sent from my SPH-L710 using Tapatalk
Click to expand...
Click to collapse
The re-odex does happen on the phone and the files are pulled back onto the pc so you can install them when ready. The install command puts everything from your "playground" into the right place on the phone. I plan on still making a function to create a flashable zip, but haven't gotten there yet. Even without the flashable part it still makes things a lot quicker for developing and testing. Also plans on storing mods as patch files and scripts to log your work so you can repeat the same processes on different base systems in one command.
Sent from my SM-G900P using XDA Free mobile app
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