with attachment now :) T
On Fri, Jan 8, 2016 at 2:49 PM, Thomas Voß <thomas.v...@canonical.com> wrote: > On Fri, Jan 8, 2016 at 2:55 AM, Daniel van Vugt > <daniel.van.v...@canonical.com> wrote: >> That all said, there might be a short-cut. If you accept that it may >> only work on Ubuntu phones that were formerly Android phones, then with >> maybe some weeks/months of effort you might be able to build the >> required translation layers for graphics and input etc... >> >> > > The approach would not necessarily be limited to phones (or devices > that used to be Android devices). > I illustrated a hypothetical stack (and a bigger picture) in the > diagram attached to this mail. In that diagram: > > * orange boxes refer to services and middleware provided by Ubuntu. > Please note that > the respective layer in the diagram refers to arbitrary system services. > * green boxes refer to Android drivers (binary blobs). Please note > that we are able to consume those drivers > without modifications and as they ship for Android (built against > bionic etc.). > * the dotted rectangle refers to a potential container hosting the > app and its runtime. It is not strictly required, though, depending on > the > type of app (pure java would likely not require a container, apps > using the ndk might likely need one to provide necessary elements like > bionic). > Please note that the "Android container hosting apps" is a thought > experiment only, we haven't done this for Android apps, only for > legacy X11 applications. > > With that, we are able to swap out the Android (driver) layer and > replace it with alternatives (e.g. on vanilla linux setups). > The app could follow along together with the emulation layer and "just > keep on working". This is subject to a few unknowns though, > specifically > on the set of services that an app requires. If the app was deeply > integrated with Android, there is a fair chance that one or more > services provided by Android cannot be > mapped to the Ubuntu platform. > > A closing remark on the "Android emulation layer": It could > theoretically be Android itself (with the app and the layer running in > an LXC container) in which all > required system services have been patched to talk to the Ubuntu side. > It would require significant effort, but I think it *could* work. > > HTH, > > Thomas > >> On 08/01/16 09:21, Daniel van Vugt wrote: >>> Support for Android apps is unlikely to happen any time soon. >>> >>> You have to remember that Ubuntu Touch is not Android, but is a full >>> Ubuntu system. The fact that Ubuntu Touch uses an Android kernel is not >>> sufficient to support Android apps. >>> >>> Although parts of Android remain and are visible in the Ubuntu Touch >>> filesystem, they are unlikely to function correctly. Certainly even if >>> you could run an Android app right now then it would not appear on the >>> screen. That would require significant work. And even still, not all >>> Ubuntu Touch devices will be based on Android devices. So you would >>> really need to start from the ground up and build a self-contained >>> Android emulator. >>> >>> >>> On 07/01/16 17:53, 유재용 wrote: >>>> Come to think of it, by replacing surfaceflinger, would it be possible to >>>> >>>> run Android apps as it appears as a native application in Ubuntu touch? >>>> >>>> In other words, if you run Angry bird in Ubuntu touch, it will launch >>>> >>>> Angry bird in Android and the screen output is composed to the application >>>> >>>> inside Ubuntu touch? >>>> >>>> Thanks, >>>> >>>> Jaeyong >>>> >>>> ------- *Original Message* ------- >>>> >>>> *Sender* : Andreas Pokorny<andreas.poko...@canonical.com> >>>> >>>> *Date* : 2016-01-05 03:07 (GMT+09:00) >>>> >>>> *Title* : Re: Re: Regarding running Android LXC guest in Ubuntu touch by >>>> using Mir >>>> >>>> >>>> On Mon, Jan 4, 2016 at 6:50 AM, 유재용 <jaeyong....@samsung.com >>>> <mailto:jaeyong....@samsung.com>> wrote: >>>> >>>> Oh, I see. That is more interesting. >>>> >>>> Just for the curiosity, could you tell me more about the early days >>>> before Mir? >>>> >>>> I'm wondering why you choose to remove surface flinger. >>>> >>>> Is there some constraint if you keep using Surface flinger and >>>> another graphics server? >>>> >>>> Thanks, >>>> >>>> Jaeyong >>>> >>>> >>>> Hi Jaeyong, >>>> Replacng surfaceflinger with a mir based system compositor - next to the >>>> obvious idea of making the android driver based stack similar to the >>>> mesa/kms based stack - allows us to separate the user session from the >>>> output and input devices allocation. With that it will be easy to have a >>>> seamless switch between user sessions or have them running in parallel >>>> and move devices between sessions .. and more. >>>> >>>> regards >>>> Andreas >>>> >>> >> >> -- >> Mir-devel mailing list >> Mir-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/mir-devel
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
