FORUMS
Remove All Ads from XDA

[GAPPS][DAILY] Open GApps for Android; All Android Versions & Devices

811 posts
Thanks Meter: 2,243
 
Post Reply Email Thread
3rd May 2015, 11:43 PM |#11  
Member
Flag Minneapolis
Thanks Meter: 4
 
More
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?
The Following 2 Users Say Thank You to DJAlik For This Useful Post: [ View ] Gift DJAlik Ad-Free
 
 
4th May 2015, 06:24 AM |#12  
Member
Flag Minneapolis
Thanks Meter: 4
 
More
Chrome doesn't seem to be working. It crashes every time I try to run it.
4th May 2015, 08:32 AM |#13  
OP Recognized Developer
Flag The Hague
Thanks Meter: 2,243
 
Donate to Me
More
Quote:
Originally Posted by DJAlik

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?

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.

Quote:
Originally Posted by DJAlik

Chrome doesn't seem to be working. It crashes every time I try to run it.

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.
The Following 2 Users Say Thank You to MastahF For This Useful Post: [ View ]
4th May 2015, 08:40 AM |#14  
OP Recognized Developer
Flag The Hague
Thanks Meter: 2,243
 
Donate to Me
More
Quote:
Originally Posted by hellowasif

Yes that will be wonderful to work as a team and you count me in.

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!
The Following 2 Users Say Thank You to MastahF For This Useful Post: [ View ]
4th May 2015, 01:06 PM |#15  
Senior Member
Flag Naples
Thanks Meter: 130
 
More
Quote:
Originally Posted by MastahF

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!

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).
4th May 2015, 01:19 PM |#16  
Member
Flag Minneapolis
Thanks Meter: 4
 
More
Quote:
Originally Posted by MastahF

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.

latest commit:

$ sh make_package.sh
rm: missing operand
4th May 2015, 02:09 PM |#17  
OP Recognized Developer
Flag The Hague
Thanks Meter: 2,243
 
Donate to Me
More
Quote:
Originally Posted by DJAlik

latest commit:

$ sh make_package.sh
rm: missing operand

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.
4th May 2015, 02:25 PM |#18  
OP Recognized Developer
Flag The Hague
Thanks Meter: 2,243
 
Donate to Me
More
Quote:
Originally Posted by Rapper_skull

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).

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.
The Following 2 Users Say Thank You to MastahF For This Useful Post: [ View ]
4th May 2015, 02:46 PM |#19  
Senior Member
Flag Naples
Thanks Meter: 130
 
More
Quote:
Originally Posted by MastahF

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.

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.
4th May 2015, 03:00 PM |#20  
Member
Flag Minneapolis
Thanks Meter: 4
 
More
Quote:
Originally Posted by Rapper_skull

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.

I've been using Cygwin on Windows and the scripts work great.
4th May 2015, 03:08 PM |#21  
Senior Member
Flag Naples
Thanks Meter: 130
 
More
Quote:
Originally Posted by DJAlik

I've been using Cygwin on Windows and the scripts work great.

I had no doubt. Cygwin is a solid tool with a long story and all the applications used by the scripts are present in all distros. The only problem is that installing Cygwin is sometimes a plague for a complete environment. BTW an eventual Windows port is the lowest of the priorities.
Post Reply Subscribe to Thread

Tags
gapps, open gapps, open source, opengapps

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes