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?
Hi,
When you want to perform some scripts at boot-time, there is two possibilities :
- modify init.rc, but it requires to reflashing the rootfs image (modification in / does not hold after a reboot),
- using an android app like script manager, which will load your scripts at java/dalvik platform boot-time.
I've managed to find a way based on activating tf-daemon, which is a script called by the asus/ventana initrc, but disabled at boot-time. Basically, we're re-enabling this daemon by setting the property tf.enable to yes, and then creating a script called tf-daemon and put it in /system/bin. Since this script is called by init.ventana.rc as root, you can put whatever you want inside this script.
I don't know what is the original purpose of this daemon, but probably it's used by the asus team for internal and debugging purpose.
Be aware that in the next firmware update, this possibility could disappear.Let's hope the asus team does not read this post. Or at least they could allow power users to call custom scripts at boot-time.
As a case study, you will find as attachment a script for loading nfs modules at boot-time.
PS: damn, can't upload. Here is a temporary link : http://dl.free.fr/hwTZ0YBq2
Untar the archive, then su, and sh install.sh
At reboot, you should have nfs modules loaded.
Good find:
I gave this a try just to load a couple of my own modules that work with the kernel I'm using. Works fine -- Thanks, -
Another method is to make a script and just call it in the init.rc. After a firmware update you only have to add the "exec myscript.sh" line to init.rc. I personally prefer this method because it allows me to control when the script is executed, whereas the tf-daemon method is always executed at the same point(AFAIK). Good research though, always nice to know all the boot calls.
Modifying the init.rc was my first shot, but the problem is that init.rc lies in ramdisk. So when trying to modify, the modification does not hold
after reboot. So a real modification involves to reflash rootfs with nvflash, too much hassle for me. The method I'm providing is for lazy ones. ;-)
nice find, but the link is dead, could you please provide a new link for the script?
also, how do I load nfs module for there is none under /lib/modules, compile the kernel myself?
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.
What's ziplign ?
Read,Android Developers site.https://developer.android.com/studio/command-line/zipalign
zipalign is an archive alignment tool that provides important optimization to Android application (APK) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. Specifically, it causes all uncompressed data within the APK, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application.
This tool should always be used to align your APK file before distributing it to end-users. The Android build tools can handle this for you. Android Studio automatically aligns your APK.
Click to expand...
Click to collapse
Why this tool is needed ?
There are a lot of APK modifications on XDA, most of which are done through APKTOOL (Thanks @iBotPeaches for this great tool)
But after apktool compilation, apks needs to be zipalign manually -> which is missing from some these Modded/Distributed Apks found in the forum.
So, I decided to go ahead and make simple tool for this task.
This tool will help end-users/devs in such cases.
How to Use ?
It's One-Click tool, As simple as it gets !
Download & Extract Zip file from attachment.
Put All apks in "Input" folder
Do not leave "SPACES" in file name of APKs For example, Use "AppName_v1.apk" instead of "AppName v171.apk"
Double Click the Batch file (.bat)
You can find zipaliged APKs in "Output" folder after it's done.
That's It !!
PS : (Devs only) Use this tool **AFTER** signing APKs
Users don't need to worry about this because APKs you have/download are already signed.
FAQs
# How to know whether APKs are zipaligned or not after using this tool ?
Check file size of APK Before & After (In Input & Output folders). You will see the differnce in file size on bytes level So, you need to open full property of file via right click.
If file size if exactly the same, means APK was already zipaligned
# How to know whether APKs i have are already zipaligned or not ?
As of now there's no method to my knowledge. So, you need to go through above process.
In general, APKs directly from PlayStore (you backup/apkmirror) are zipaligned so you don't need to zipalign them unless there's some modifications performed on it.
Change log
v1.0 Release 2017
Initial Release
Latest available zipalign binary
v2.0 Release 2022
Based on Android SDK Build-Tools 30.1.0 and should be compatible with latest Android versions (A9-A12+)
Tried this. Nothing in the output folder
Serpentinefire76 said:
Tried this. Nothing in the output folder
Click to expand...
Click to collapse
I'm not actively maintaining this tool due to personal commitments. Theoretically it should still work even with older binaries but if you are looking for specific support I suggest search for other/newer threads.
jineshpatel30 said:
I'm not actively maintaining this tool due to personal commitments. Theoretically it should still work even with older binaries but if you are looking for specific support I suggest search for other/newer threads.
Click to expand...
Click to collapse
I tried it again. It works like a charm. Awesome. Thank you!
Update after a long time.
v2 is based on Android SDK Build-Tools 30.1.0 and should be compatible with latest Android versions (A9-A12+)
Happy Modding!
i get this error a mod apk
Code:
Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES: Failed collecting certificates for /data/app/vmdl262490375.tmp/base.apk: Failed to collect certificates from /data/app/vmdl262490375.tmp/base.apk: META-INF/APKEASYT.SF indicates /data/app/vmdl262490375.tmp/base.apk is signed using APK Signature Scheme v2, but no such signature was found. Signature stripped?]
Command file current zipalign.bat:
for %%X in (.\Input\*.apk) do (
echo Zipaligning - %%~nX.apk
.\Tools\zipalign -cv 4 %%X
.\Tools\zipalign -fv 4 %%X .\Output\%%~nX.apk
)
Maybe it should be reversed like this:
for %%X in (.\Input\*.apk) do (
echo Zipaligning - %%~nX.apk
rem To align infile.apk and save it as outfile.apk
.\Tools\zipalign -fv 4 %%X .\Output\%%~nX.apk
rem check alignment outfile.apk only after having zipalign (does not modify file)
.\Tools\zipalign -cv 4 %%X
)