Kivy
Allow the gradle file templates to be overridden in python-for-android
#8
Replies: 7 comments 19 replies
-
|
Please explain in more detail. How are they "hidden"? How would they be "exposed"? What hurdle are you facing? |
Beta Was this translation helpful? Give feedback.
-
They are hidden in the fact that i can't edit them for my need
Projects flutter exposes them in an android folder
2023-10-27T04:11:55.8069052Z Welcome to Gradle 7.4.1!
2023-10-27T04:11:55.8069569Z
2023-10-27T04:11:55.8069770Z Here are the highlights of this release:
2023-10-27T04:11:55.8070458Z - Aggregated test and JaCoCo reports
2023-10-27T04:11:55.8071198Z - Marking additional test source directories as tests in IntelliJ
2023-10-27T04:11:55.8071981Z - Support for Adoptium JDKs in Java toolchains
2023-10-27T04:11:55.8072381Z
2023-10-27T04:11:55.8072822Z For more details see https://docs.gradle.org/7.4.1/release-notes.html
2023-10-27T04:11:55.8073612Z
2023-10-27T04:11:55.8073900Z Starting a Gradle Daemon (subsequent builds will be faster)
2023-10-27T04:11:55.8074787Z WARNING:We recommend using a newer Android Gradle plugin to use compileSdk = 34
2023-10-27T04:11:55.8075393Z
2023-10-27T04:11:55.8075722Z This Android Gradle plugin (7.1.2) was tested up to compileSdk = 32
2023-10-27T04:11:55.8076259Z
2023-10-27T04:11:55.8076435Z This warning can be suppressed by adding
2023-10-27T04:11:55.8077021Z android.suppressUnsupportedCompileSdk=34
2023-10-27T04:11:55.8077660Z to this project's gradle.properties
2023-10-27T04:11:55.8077989Z
2023-10-27T04:11:55.8078417Z The build will continue, but you are strongly encouraged to update your project to
2023-10-27T04:11:55.8079419Z use a newer Android Gradle Plugin that has been tested with compileSdk = 34
2023-10-27T04:11:55.8080178Z > Task :clean UP-TO-DATE
2023-10-27T04:11:55.8080609Z > Task :preBuild UP-TO-DATE
2023-10-27T04:11:55.8081086Z > Task :preDebugBuild UP-TO-DATE
2023-10-27T04:11:55.8081786Z > Task :mergeDebugNativeDebugMetadata NO-SOURCE
2023-10-27T04:11:55.8082387Z > Task :compileDebugAidl NO-SOURCE
2023-10-27T04:11:55.8082958Z > Task :compileDebugRenderscript NO-SOURCE
2023-10-27T04:11:55.8083503Z > Task :generateDebugBuildConfig
2023-10-27T04:11:55.8083951Z > Task :javaPreCompileDebug
2023-10-27T04:11:55.8084393Z > Task :checkDebugAarMetadata FAILED
2023-10-27T04:11:55.8084729Z
2023-10-27T04:11:55.8084915Z FAILURE: Build failed with an exception.
2023-10-27T04:11:55.8085267Z
2023-10-27T04:11:55.8085390Z * What went wrong:
2023-10-27T04:11:55.8085901Z Execution failed for task ':checkDebugAarMetadata'.
2023-10-27T04:11:55.8086871Z > Could not resolve all files for configuration ':debugRuntimeClasspath'.
2023-10-27T04:11:55.8089922Z > Failed to transform geckoview-nightly-121.0.20231026172553.aar (org.mozilla.geckoview:geckoview-nightly:121.0.20231026172553) to match attributes {artifactType=android-aar-metadata, org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.libraryelements=aar, org.gradle.status=release, org.gradle.usage=java-runtime}.
2023-10-27T04:11:55.8093976Z > Execution failed for JetifyTransform: /home/runner/.gradle/caches/modules-2/files-2.1/org.mozilla.geckoview/geckoview-nightly/121.0.20231026172553/1a1bb67df1484ed8b1e109b4467c70c0e2750da1/geckoview-nightly-121.0.20231026172553.aar.
2023-10-27T04:11:55.8095757Z > Java heap space
2023-10-27T04:11:55.8096106Z
2023-10-27T04:11:55.8096212Z * Try:
2023-10-27T04:11:55.8096687Z > Run with --stacktrace option to get the stack trace.
2023-10-27T04:11:55.8097448Z > Run with --info or --debug option to get more log output.
2023-10-27T04:11:55.8098118Z > Run with --scan to get full insights.
2023-10-27T04:11:55.8098461Z
2023-10-27T04:11:55.8098656Z * Get more help at https://help.gradle.org
2023-10-27T04:11:55.8099042Z
2023-10-27T04:11:55.8099604Z Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
2023-10-27T04:11:55.8100302Z
2023-10-27T04:11:55.8101237Z You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
2023-10-27T04:11:55.8102203Z
2023-10-27T04:11:55.8102756Z See https://docs.gradle.org/7.4.1/userguide/command_line_interface.html#sec:command_line_warnings
2023-10-27T04:11:55.8103490Z
2023-10-27T04:11:55.8103622Z BUILD FAILED in 1m 1s
2023-10-27T04:11:55.8104119Z 4 actionable tasks: 3 executed, 1 up-to-date |
Beta Was this translation helpful? Give feedback.
-
|
I think @baseplate-admin has a good point, this is what I would suggest (and why it would not be a good suggestion!!): I would like to kill almost all the buildozer.spec Baroque because buildozer.spec has too many options. The growth of these options has been organic, there is no big picture. And the two lines of text are insufficient to document the behavior they implement, unless you already know. Backwards because most of the time when I want to set some unusual option it it because I read about it in the Android documentation and it is documented there in terms of AndroidManifest.xml code. Sooo I go to the template in p4a, find the option that is in the right place, then look in buildozer.spec for that option name. The process is backwards, and depends on knowing where to look in p4a. Unfortunately I think this suggestion would create a long term support problem. If p4a developers want to change AndroidManifest.xml then there is no backwards compatibility for existing apps with an updated p4a. And a version tag would give app owners a surprise update task. I did consider the better documentation approach. And concluded that would be the template AndroidManifest abstracted in some way and annotated with 'this option goes here'. But documenting our abstraction by removing it is a soul destroying task, as it seems to indicate a fundamental problem with the abstraction. So I don't think I have a good suggestion. But I do think there is an issue. |
Beta Was this translation helpful? Give feedback.
-
|
My argument against what you are describing is not that it is a bad idea, but that it isn't "Buildozer". Buildozer's selling point seems to be "One spec file in one place for all your cross-platform build config." If you don't agree with that vision (which may well be a justified stance), you may as well start again, and substitute a different tool driving p4a. [Another issue: I don't think the Buildozer team has the development velocity to tackle this with reinforcements.] |
Beta Was this translation helpful? Give feedback.
-
It tries to be 2 things at once. A cross compiler and a configuration generator. It should do one thing and one thing only ( in my eye that is to be a good builder and not a config generator )
I partially agree on this. It's high time we moved to a real build tool. ( something like pants maybe a good candidate because it supports
I can give a hand in solving this issue. I think this discussion needs to happen. For the future of kivy |
Beta Was this translation helpful? Give feedback.
-
|
The main Android app I want to build cannot be build by Buildozer/p4a, because the templates can't be used to make the right Android Manifest. The solution I am thinking of (and have no concrete plans to implement) is ANOTHER BuildSpec option (with the obligatory 2 line explanation 😉) which is a pathname to a manifest xml that completely overrides all the other options and simply substitutes in the provided file. I wonder if a similar option will satisfy @baseplate-admin. [I confess I have no idea what "Projects flutter exposes them in an android folder" and the given error log means.] |
Beta Was this translation helpful? Give feedback.
-
Take a look at this repository, it includes This entire folder lives in this path in That is what i want to modify.
it probably means that the version of gradle used to build the project should be higher than |
Beta Was this translation helpful? Give feedback.
-
I want to modify |
Beta Was this translation helpful? Give feedback.
-
Oooooh! I didn't think of that. Yes! |
Beta Was this translation helpful? Give feedback.
-
Yes, I can see this. In my world I thought about this as an old/new transition flag (More detail than was needed above). But yes, this is at least a catchall. The support answer is then always yes 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
The current workflow can be easily modified by having the to be used manifest file being put in some designated easily accessible folder by buildozer and use that file for future changes and builds. Also, we can have another thing to be added in buildozer is to follow the spec of android manifest as theres only a handful of directives to be used we can may be expose just one arg in buildozer spec that can take up any of such xml scripts or files and put them in to the relevant manner. But then this might end up being more complicated then to have just the manifest being rendered once and put into a folder with ease of access and being used during the build. This will need to change just two path lookup behaviours but for end users it wont feel any different. for advanced users they can utilize it though. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Is this on the roadmap? Not being able to modify the p4a files seems to be a roadblocker for my project. Any way i can contribute that fix? |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn't rely on it being on any roadmap in the short-term. For the core developers, there are many hundreds of suggestions to consider. If it is a road-blocker for you, I would suggest you need to spend some resources on it, and take the lead. |
Beta Was this translation helpful? Give feedback.
-
Great to hear this. I was wondering if it was possible to discuss about some of the implementation of this approach ( cause the last thing we want is i do all the work and the PR doesn't get merged ) |
Beta Was this translation helpful? Give feedback.
-
|
If you don't get any engagement here, I suggest the #dev channel in Discord. |
Beta Was this translation helpful? Give feedback.
-
|
@baseplate-admin if you need to replace AndroidManifest directly, I explained how to do it here on this repo. The only issue is that you need to compile the app first, then enter on the This is what I need to do every time I need to modify Or we could build a GUI program using Kivy and package it to all desktop systems, this GUI would show all these options from |
Beta Was this translation helpful? Give feedback.
-
|
See the last file: Under my proposal, you would be "exposing" all the files under bootstraps/[whatever], so it would include the ones you want and the ones I want, and there would only be one new option (no matter how many new bootstraps are written). |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
@RobertFlatt Thanks! The term I was looking for was MediaStore service, so media players (like the example given, but more importantly for me, Android Auto systems) can play it. |
Beta Was this translation helpful? Give feedback.
-
|
I think we can do one small change. So buildozer when initialized shall always generate the partially rendered templates in an accessible top level folder. This folder can be modified by the users easily and when building the app buildozer rather than rendering the templates shall only take the partially rendered templates from the accessible top level folder. This shall allow for easy modification while not burdening any mandatory changes on others who don't need them. On buildozers part, the changes would be to perform partial rendering of the templates with jinja2, etc. during init in a top level folder and to refer to that folder during build for further rendering and app building. This entails changing of paths for operation of the build. But having the templates rendered during build entails ambiguity in template choices and customization. So we can introduce one more step in between init and build , in which this partial rendering is done. If someone doesn't do this, then the path shall not exist and buildozer shall fallback to its original behaviour. This seems easy to implement as there's only path changes involved and no extensive code rework might be needed. This shall also be easier to implement over p4a side rather than burdening p4a to accept every argument provided by buildozer and build that functionality over p4a or kivy-ios. Consequently, the only viable alternative is to follow react expo or flutter behaviour in which they have implemented the total manifest spec through their config options and always need to be in sync with latest updates. Though this can lead to a more pythonic (friendly) approach to config changes but entails a tremendous amount of spec work in the beginning. Once that's done, keeping in sync with the spec shall be a matter of doing atomic updates. |
Beta Was this translation helpful? Give feedback.
-
This goal aligns itself with https://github.com/orgs/kivy/discussions/3 . ( @FilipeMarch please take a note of this ) To be honest, i like exposing the |
Beta Was this translation helpful? Give feedback.
-
While hiding everything behind
p4aseems like a good idea at first, for those of us who have complex requirement, this becomes a hurdle.Please expose the template files in here
https://github.com/kivy/python-for-android/tree/fbe9fe496363c5b46427407b3a5c59099e02cfbc/pythonforandroid/bootstraps/common/build/templates
Beta Was this translation helpful? Give feedback.
All reactions