![]() Registered Member ![]()
|
This is a thread for questions to the devs on how android integration will work.
2. Will we ship our own libdvm.so or libart.so? 3. Where will we install them, /opt/andvm/<pkg>? 4. Will apps have filesystem access or an emulated filesystem? 5. How will we replace most applications' dependencies on the google play services? ie. Push Notifications, in-app purchases 6. Will android support be handled like a standard library installation? ie. # apt-get install plasma-android-support 7. Will plasma-phone ship with android support, or downloaded separately? |
![]() KDE Developer ![]()
|
Heyhey
![]() That's quite a bunch of questions, there, hope i can answer you properly, here... 1. Apps will, eventually, be launched from the application launcher (shashlik will, on app installation, create a .desktop file for the application and put it in a discoverable location). 2. Yes ![]() 3. They will need to be installed inside the android filesystem that shashlik uses. Optionally, we might be able to create a data location per user, and integrate this with the proper linux user system, but this isn't really a part of the plan as yet - a little early for that, but worth considering, certainly. 4. Filesystem access, because otherwise it would not be on Real Linux, so to speak, which is the whole point. The security layer will be the same as found in the rest of your desktop, and so an application launched by you will be able to read the files your user account has access to (and so on). If you want to limit this access, you will need to add a user for the shashlik process and launch things through that user (which, certainly, is not unreasonable to do, depending on the apps you decide to run) 5. We won't. If apps require google services, google services will need to be installed. It is either that, or we will need to reimplement each of them. This is certainly an option, however, at least for some services. 6. That is the basic plan, yes - it will obviously depend on your distribution (in my case that means opensuse), but given the nature of shashlik, it would make sense to not split it up much further than basic-shashlik-stuff (like the controller application), and android-stuff (as a sort of data package, a la the support data for other applications), but speaking just for me, a single package (plus devel+debug packages) would make sense. 7. Shashlik is not directly linked with plasma-phone, and for now it is out of scope to run Shashlik on arm platforms. It will happen in the future, but it is a little premature to consider the technical solutions for that at the moment. Hope that helps clarify things a bit! Thank you very much for the questions ![]()
..Dan // Leinir..
http://leinir.dk/ |
![]() Registered Member ![]()
|
Thank you for getting back to me.
For people who aren't nose-deep in the project or normally a part of the KDE ecosystem, it can be hard to see how things will fit together; maybe this'll be of use to some people. So, as a recap and clarification: shashlik is a project designed to simulate an android environment for non-android platforms. Repo is here: https://github.com/shashlik/shashlik AndApps will not be segregated from the 'normal' applications, and follow the following specification: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html Dalvik will be used until ART becomes stable-standard, part of shashlik. AndApps will be accessible from all users for the time being. Possible to add another security layer by limiting AndApps' execution to a single unprivileged user. On our own for freedom from Google for now, unless we reimplement each of their services. Support for AndApps will be easy to install. Shashlik for ARM is not ready, but that's the plan. Cool! Thanks. Notes: I've been looking into replacing Google's services with FOSS replacements, hopefully as drop-ins, and here's what I've found. Alternative for GCM: https://github.com/airnotifier/airnotifier Billing (depreciated and gone as a google service: https://github.com/robotmedia/AndroidBillingLibrary and I'm sure there's more. Sorry, more questions! 1. Will the .desktop files be generated from the AndApp's metadata? Where would we get this data from? ie. online repo/built-in package info 2. How will root-required apps be handled? (and special permissions in general?) I looked in the shashlik repository, and found no special mention of root/superuser/etc. |
![]() Registered Member ![]()
|
What do you think of this: https://microg.org/?
To the superuser Question: I don't think android root apps would make sense on plasma-mobile. As example an app which installs the latest busybox couldn't be used, it qould just install busybox inside the virtual android which woudn't have any use. My Idea for apps in general: Make an app manager which can install / uninstall android apps, plasma-apps, ubnutu phone apps . . . Everything in just one app. |
![]() Registered Member ![]()
|
really cool,
but Shashlik means barbeque from russian ![]() |
![]() Registered Member ![]()
|
Should be part of the picture in my view So many Android apps rely on Play Services and will either break, or constantly complain when those services aren't available microG does an awesome job of impersonating Play Services Until such time as Plasma Mobile or UBPorts are available more broadly I'm using the unofficial microG build of Lineage It's awesome to have a functional Android without all the Google crud Use as much open source stuff from F-Droid as you can, then use Yalp Store to fill in any blanks But at the end of the day, it's still Android. I'd much rather be running a proper Linux OS, but for the moment, we are where we are |
![]() Registered Member ![]()
|
Will Plasma Mobile ever be available to download and install on any unlocked Android type smart phone to replace the Android distro.?
|
Registered users: Bing [Bot], Google [Bot], kesang, Yahoo [Bot]