AAB support related changes #2467
Conversation
Will after these changes p4a can't build apk's? |
It's probably important to keep APK generation, this is still the Android package format and what you'll use for local development, direct sharing with others or (as it stands) upload to stores other than the Play store. |
|
Updated "Drop apk generation" to "Drop current apk generation method". I expect to support apk generation via
Some interesting references: https://developer.android.com/studio/command-line/bundletool#generate_apks |
|
It would be great to get rid of The reason for a We know Google looks into Did anybody test if Google will accept a |
misl6
force-pushed
the
feat/aab-support
branch
2 times, most recently
from
2557ec8
to
46dd7e8
Compare
misl6
force-pushed
the
feat/aab-support
branch
3 times, most recently
from
f94a49f
to
3755ab1
Compare
|
Some updates:
|
|
Again, some updates:
Weekend checklist:
|
misl6
force-pushed
the
feat/aab-support
branch
4 times, most recently
from
e3c95b6
to
e1e2bd0
Compare
|
Since august 3rd, I confirm that I have been able to build AAB (including multiple architectures Arm-v8a & Arm-eabi-b7) with this branch: |
|
I hope that these changes can soon be integrated in the master branch. |
misl6
force-pushed
the
feat/aab-support
branch
2 times, most recently
from
9bfaf33
to
8df9880
Compare
|
I tried to use this to build
The build fails with which is correct: Build again without deleting anything gives: and Looks like a state machine issue, is there any workaround? |
|
The previous issues appear fixed, but there is another Which is correct: The log says the dist was built, I don't know if this means I should expect a .aab , but |
|
@RobertFlatt I've just updated the PR with a fix that should fix your issue. Thank you for testing. |
|
Great,
Can you tell me how to run But all I can find is Since devil is a couple of directories up, I assume there is some command somewhere... I found Or maybe I have to install the Java version? Enhancement request : Execute bundletool in p4a, any user with half a brain will want to test the aab by installing the derived apks on Android. Seems automation (run bundletool and unzip) would be a good thing. |
|
I'm using Hello World, and the .p4a above. On the first build the .aab is about 50M. I'm surprised, but that is not new! The .aab increases in size by about 24M with each run 51M, 74M, 98M,...... Deleting ~/.gradle before each build stops the increase. I'm stuck on a one way street now, because whatever I do so far the output files get bigger (currently 1.2G) |
|
Arg, been using Buildozer for too long. |
|
Wait, it is only greedy for .aab, not greedy for .apk |
Nice catch, added |
|
|
@RobertFlatt , here you can find some docs about aab and bundletool: After working at this PR, I don't feel that We should integrate any Also, the result of |
misl6
force-pushed
the
feat/aab-support
branch
from
bcc30c5
to
3d54a35
Compare
misl6
force-pushed
the
feat/aab-support
branch
from
0d5770a
to
3f3420d
Compare
|
Hi, in first I'd thank you all for the development of this tool and @misl6 for the recent implementation about .aab package! I tried and had success building the aab file from @misl6 p4a's and buildozer's branch. But I only could get success by removing the Pillow from the requirements of I'm using Kivymd and it kind of depends of pillow. At the end : If I remove Pillow recipe in buildozer.spec the compilation finished like a charm but with the app probably broken. Some buildozer configs: Thanks. |
| @@ -492,11 +508,11 @@ def prepare_bootstrap(self, bootstrap): | |||
| def prepare_dist(self): | |||
| self.bootstrap.prepare_dist_dir() | |||
|
|
|||
| def get_site_packages_dir(self, arch=None): | |||
| def get_site_packages_dir(self, arch): | |||
There was a problem hiding this comment.
Making the arch parameter no longer optional breaks existing code. Was this intentional?
There was a problem hiding this comment.
I saw this too kivy/buildozer#1356 (comment)
and documented https://github.com/Android-for-Python/Android-for-Python-Users#release-builds
Apparently it is intentional, but I wish it wasn't:
https://discord.com/channels/423249981340778496/678695971164520523/893188780020871188
There was a problem hiding this comment.
Hi @dlech ,
Unfortunately, previously, the arch argument was useless.
Now instead, is needed in order to select the correct folder, based on the arch you're currently building for.
If some recipe is broken (We noticed in #2496 that our CI wasn't running as expected) or this change is breaking something for you, and the change could also meet someone else needs, I will schedule it as a feature-request.
There was a problem hiding this comment.
No worries, it was a one-line fix. This PR was huge, and sometimes things slip through unnoticed, so I just thought I would ask.
The arch argument of get_site_packages_dir() is no longer optional. Comes from changes in kivy/python-for-android#2467
* Added support for aab * Move to build:gradle:3.5.4 (adds support for API 30), fix some tests * Github actions test apps (apk + aab) * Add missing bdistaab * Fix automated tests * ndk lib folder (or ndk platform) now is ABI specific * Fixes dist lookup + some tests * Added .aab and .apks to blacklist * Interrupt build and alert the user if tried to build an aab in debug mode * Updates troubleshooting instructions to reflect current structure. * Exclude gdbserver and gdb.setup from release builds * Add a paragraph in history + fixes --arch docs * Fix versioning * Minor fixes to docs * Some code cleanup * Removes unusued versioning logic in unpackPyBundle and add a FIXME
Is marked as WIP, cause the main target of this PR is to open a discussion around potential changes, and how to restructure some p4a functions in order to support AAB (See #2084).
Apart from the new (currently useless),
aabbuild option, the current changes are basically doing the following:The old
private.mp3tar file, is now been moved fromassets/private.mp3tolib/xxx/private.so, where "xxx" is the targeted ABI. (This is necessary due to Split custom assets by device ABI? google/bundletool#190)The new
lib/xxx/private.sois now unpacked from thegetApplicationInfo().nativeLibraryDirreported folder to the same target as before.Now the version check is skipped for obvious reasons. We should re-implement this feature via (as an example) an md5 hash? (Better if We do that at build time, skipping the md5 hash generation during runtime)
Next steps:
private.soby splitting it in two parts (ABI-specific parts(_python_bundle)) and NON-ABI-specific (that could be shipped into assets like We're already doing))_python_bundleso it is easier to build the bundle later.bundletool.I rarely have some spare time, so help is always appreciated.