Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request / Idea / Poll: Create kex packages #917

Closed
KeyWeeUsr opened this issue Oct 26, 2016 · 3 comments
Closed

Feature request / Idea / Poll: Create kex packages #917

KeyWeeUsr opened this issue Oct 26, 2016 · 3 comments

Comments

@KeyWeeUsr
Copy link
Contributor

I encountered a new and an interesting way how to look at the android apps that would work in a similar way as the launcher is at SO. Or even extend the launcher itself.

I'm not really sure how to do it, but p4a would need an option to compile a package, not package it into apk, which then could be packaged into kex file. It's directed probably the same way as the idea with already compiled builds to be able to work on Windows. Most likely it's already there, just an argument(s) missing to run recipes only.

Then there could be a bool in App class, which would have a method that already loads kex files from a location (SD card?).

It might be overkill, but it doesn't really have to be, because:

  • smaller App size (interpreter only)
  • more flexibility, packages could be packaged as a standalone (non-runable) applications like e.g. some libraries or hidden apps on Android i.e. plugins for an application
  • more flexible package updates

Yet there's a con - if not secure enough, a user could misuse packages and well... get into the app, get the source and all other fancy stuff just by playing with a package loading. This con is not present if talking only about the use of launcher.

It's basically almost the same as placing a compiled package into a folder with main.py, but more user-friendly or beginner-proof. I'm not sure if this is a good way for p4a or not, so... if you can, vote here(those github post "reactions"), or just close if it's too offtopic. 😄

@inclement
Copy link
Member

I'm not quite sure what you're proposing here - you'd split the python build into multiple apks that load each other?

@KeyWeeUsr
Copy link
Contributor Author

KeyWeeUsr commented Oct 29, 2016

Kind of, yes. The main idea is to compile app deps into separate packages that could be replacable. That functionality is already there, but wrapped with the whole installing to python and deploying to apk. This would leave an option to get those packages without searching for them or cutting from the already compiled apk.

The second part (plugin-like app), this is similar to how Qt handles things with linking to its core if you don't want to pay for the less restrictive license, but this would be on android. An example for this kind of app is MX player that handles codecs this way. And it could _probably_ open a way for working with C dependencies that have very restricted licenses that won't allow you to build a single package, only to link. Not sure about the last sentence, it's still kind of mystery to me if an apk counts as a single binary, or just as an archive with multiple binaries (law).

@KeyWeeUsr
Copy link
Contributor Author

closing because of kivy/kivy#3594 and kivy/kivy#4819

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants