Database Info

[Q] [Attn: Devs]Gnash Cross Compilation for Android Chrome Lite

I have a few questions for the devs here. Please forgive any assumptions that may be incorrect. I've tried to do as much research as I can online but I think I need a more experienced Android dev to help me solidify my direction. Thank you in advance for your time.
That being said, I have some experience with a device known as the GP2X. It uses ARM architecture and, in the past, I have been able to cross compile for it. Notably the Stella VCS 2600 emulator. I do have some open source experience, but I've never had any formal training in programming. Seeing that Android uses the DVM to sandbox program code, I'm still a little iffy on what I can and can't get away with programatically.
First off, I've read that the Android Chrome Lite browser allows plugins/extensions through the NPAPI. I'm assuming this is the stock web browser. It's not clear to me at the moment what the default browser is or how it works. It appears that Gnash has a C++ NPAPI plugin that may need to be cross compiled and I'm hoping to get away with as little Java coding as possible.
My main questions are:
1. Does the stock browser allow NPAPI plugins?
2. If question 1 is true, does the plugin have to be compiled in ARM architecture? Are there any caveats to this?
3. From what I've been able to gather, Chrome Lite looks in the following location for Plugins:
Code:
/data/data/com.android.browser/app_plugins
Is this correct?
4. If a plugin is dropped in the correct folder, and assuming that the mime types are associated, will the Android browser recognize/utilize it? In which case, I'm sure there would be an API call that would cause it to rescan like Firefox or Opera would.
5. If cross compilation is necessary, is it better to use OpenGL, AGG, or Cairo as far as wide Android compatibility? Again, I don't know what's native or widely available in Android. I guess I'm looking for Best Practices.
I just wanted some feedback from someone knowledgeable before I go through the trouble of setting up a toolchain to handle this. Seeing that the community has been looking for a Flash player, I wanted to see if Gnash had any practical value on Android.
Thank you in advance for your time and again, please pardon my ignorance. I have holes in my knowledge and I want to get a little closer to understanding this particular subject before investing my time in development.
References:
NPAPI
http://en.wikipedia.org/wiki/NPAPI
Android Browser Plugin Path (I had to extrapolate from the batch file)
http://wiki.eclipse.org/Android_Selector_1.1
Gnash NPAPI Documentation
http://www.gnu.org/software/gnash/manual/gnashref.html#plugincppapi

[Q] X11 Server in Android

Hello,
While I am a huge supporter of the oongoing work of porting Ubuntu to the ASUS Transformer, I am more interested in seeing a native X11 Implementation. I run Debian as my primary OS and would love to be able to access native applications without the need for VNC. I do love Honeycomb, which is why I wont go pure Ubuntu​

DISCLAIMER: I AM NOT A DEV
I'm pretty sure there's a very good reason that this isn't possible. If so, it would have been implemented from the G1/Dream onward. I think it has something to do with the fact that Android really only uses the Linux kernel and thus DisplayFlinger (the video output module) has absolutely zero interoperability with X11. Also, the Android system structure (for lack of the correct term) just plain doesn't allow for something like X11 to exist.
There's pseudo-workarounds which involve having a Debian shell on your phone/tablet and then accessing it via a VNC app... but it takes over the whole screen, so you may as well just be booting into a Ubuntu partition.
http://www.androidauthority.com/run-x-windows-x11-on-your-android-smartphone-2176/
(I never got it working on any phone I own/owned though)

Android and X11 do not work together for several reasons;
First is instances owning the fb, only one is allowed to own the framebuffer, this is why on your computer you can't have more than one VT running X. The framebuffer is owned by the DisplayFlinger, Androids own XWindowManager, the flinger and X11 are not interchangeable, it is one or the other and Android apps will not run on X.
The second is libc, Android does not implement libc, but instead its own mutated library called bionic this means compiling with bionic, statically compiling, or forgetting about it. Forgetting about it is the easiest to do here because statically compiling will end up with a 100+mb xserver, which we don't want, compiling with bionic has two issues one, stripped binaries will not run on bionic, so you might as well be just running Androids display manager, and the second issue is as above.

Couldn't someone emulate a framebuffer in an android app and have X take over that framebuffer and make the app's screen be the display on this emulated framebuffer?
EDIT: I guess what I am trying to describe is that you could set up X to write to a different framebuffer than android and make an app to display this framebuffer while still keeping the android UI.

A X server for android is available.
Search github for androix-xserver. The fork of webbbn has a branch containing a lot of recent developments. Only problem with the xserver for android is building the thing. It has a lot of dependencies. It should be beter documented.

There's really no reason one could not implement a full X server against standard Android SurfaceFlinger Surfaces. Though what might be more interesting would be a library-ized version to make it simpler to bundle app + ui into a self-contained "native" Android app package.
It's just a bunch of work -- not particularly glamorous or exciting, unless you're really into porting or writing X servers -- but especially with the NDK these days supporting native apps, access to surfaces, and access to openGL, all the necessary bits are out there to make it possible

Writing a X server program that works e.g. more or less like a vnc client is likely more fun than useful. You can get around the bionic issue in many cases, but for practicle value you're just not able to make it work without z lot of effort. Better off using the vnc/x thing, a debian chroot, and an android vnc client to local host.
Sent from my Transformer TF101 using Tapatalk

I'm gonna speculate and say that it just needs to display a window on the surface flinger and render the Xorg api stuff.. also poll for taps.. doesn't seem like it would be too complex... maybe more complex to have it functioning well on every device.
Vnc will never be better than native X even if it is currently more convienent. I find it frustrating when people say something is not likely because it is tedious or trivial.
Just the fact that someone is actually working on an implementation suggests that it will happen eventually. When it is finished and works.. guess who is gonna be the only ones with the software that can do it!
They're where the people who ask these questions will eventually find themselves.
TBH, the idea of running an xserver with a chroot'd distro on my tab makes me all tingly.
tiiiiingly, kthx!
Sent from my TI-89 silver edition

The rendering stuff is one thing, issues with auth, environment, etc are another. It's slightly more complicated than filling pixels. Something you might also want to consider, doing it with a real X rather tha n the x/vnc trick, is pretty much the same. At best versus writing your own vnc client, it would *maybe* have better performance, rather than just an easy way tobsetup a .xinit/.xsession file.
Sent from my Transformer TF101 using Tapatalk

no me gusta.

Another approach
Another approach might be this
Search for X11 server with VNC backend in the market place (not allowed to post URLs)
market.android.com/details?id=com.theqvd.android.x
It is an X server with VNC backend.

It's probably just a bundle of Xvnc compiled for Linux/ARMv5 and an Android VNC client that knows how to connect to it smoothly. Basically packing what people already do, in an app.
I would also worry if the C code was replaced with a 100% Java xvnc port.
Sent from my Transformer Prime TF201 using Tapatalk

vnc x server and android
While I would love to see a native x server on android, the only way it would work is if there was a port of an android exec environment. Then you can integrate the keyboard, market and etc. But until then the UI is just... Unacceptable. HOWEVER I have been effing with it a lot and realized the best way to run Linux applications for now is to skip the desktop environment... Run xinit via xvfb vnc (tightvncserver) and to make it capture by window at your phones native res. Set options economic translate. This will run any non multimedia application B E A utifully

And then their are freaks like me that get by fine with a terminal emulators UI lol
Sent from my Transformer Prime TF201 using Tapatalk

Hi, another approach here. I think it's a native x11 server (no chroot, no vnc) written in java... there are no binaries though, only sources. If there is any dev here willing to build an apk from sources for us it would be great...

x11
afaik we can run several x11 in pc with different vts, and since x11 is a server its completely possible to write something that listens to tcp and draw stuff grab events and send tcp stuff on a single android app despite that being rly similar to vnc or rdp except vnc works on image buffers,x11 its a bit more complex... i suppose .
i use every day a winxserver at work completely independent of os window manager concluding that would be possible on a android app, (probably lots of work)

android-x11-server looks good, I'm surprised how far along it is but I'm sure the developer has a reason for not putting a downloadable APK up yet.
Something like X11->VNC works like keeping a copy of the frame buffer and figuring out what to encode and send to the VNC client for rendering. X11 and RDP I believe are more command driven, but I'm not sure about RDP. Some kind of native X11 server would rock.
Sent from my Transformer Prime TF201 using Tapatalk

I've just released an open-source X server for Android, also available through the Android Market. Details at my20percent.wordpress.com/2012/02/27/android-x-server/
Note that it's still in beta, and doesn't come with a window manager, although in theory you can run a window manager remotely.
Regards,
mkwan

Anybody here who can download mkwan's android-x11-server from the market and attach it here?
Thanks

[ROM] Android Gingerbread on Zedboard not reacting to Touch/Mouse input

Hi,
I know that Android Gingerbread is quite old so probably most people would not bother to port it any more, but I need it for a university project where the hardware resources are very limited.
After a lot of work, I managed to build Android Gingerbread for the Digilent Zedboard, but it is not reacting to any touches on my USB touchscreen or to movements/clicks with a USB mouse.
getevent provides the expected events and I tracked them in InputReader.cpp and they seem to be dispached fine, but the UI does not react to the input. I can see that the events are enqueued, but cannot find where Android actually picks up those events and works through that queue. Does anybody have an idea?
I followed a tutorial on elinux.org (I am not allowed to post links yet. It's elinux.org [slash] Zedboard_Android)
with small modifications (enabled USB touchscreens in the kernel config, switched to a different android repo since the one in the article is offline)
Any help is much appreciated.
Thank you!

Android Gingerbread is no longer supported, and cannot use Google Play Services.
Why are you trying to run Gingerbread?
Please read THIS BEFORE responding.

Thanks for the answer!
x13 said:
Android Gingerbread is no longer supported, and cannot use Google Play Services.
Click to expand...
Click to collapse
I do not need Google Play Services.
x13 said:
Why are you trying to run Gingerbread?
Click to expand...
Click to collapse
We are trying to show dynamic partial reconfiguration with Android. For that purpose, we selected the Xilinx Zynq processing system. It consists of a dual-core ARM processor and an FPGA. The point is to reconfigure parts of the FPGA from Android during runtime.
Unfortunately, we were unable to find hardware designs for the upper-level Zynq chips and do not have enough resources to build one ourselves. Therefore we are stuck with the smaller chips and went for a ZedBoard.
At a point in history (I am not sure when) there was even official android support for the ZedBoard by iveia. They used android gingerbread, thats the first reason why we chose to use it.
The second reason is that the ZedBoard has very little resources (slow processor, little RAM, no GPU), which disallow more current Android versions to run. Some people got more recent version booting (google noritsuna android zedboard), but they reported it being slow since there is no gpu and low ram (they used linux swap since the built in ram is not enough for android - but linux swap from an SD card is terribly slow). Also, we were unable to replicate their build. All build processes go through but it does not boot. No debug output is available - not even kernel messages over UART. I suspect the u-boot setup is wrong but am no expert and cannot fix it.
Gingerbread is working fine (except for the touch issue), so we decided to stick with it.

Force area of memory to remain at compile time on Android

I tried to post this in the development forum, but I am not allowed.
I am tinkering with ARM architecture and Android device development and low level OS stuff. I am currently using QT C++ for Android for app development. This works great for all of my standard Android app development, but now I am digging deeper. I am doing an experiment where I have a small binary blob (64k) of ARM code that I want to load into memory at run time using mmap(). In order for this code to work, it needs to be loaded at address 0x22000000. In my C++ code i call mmap(0x22000000, ...) which would map the binary file to that address only if it were not in use already, which it is on a couple different android devices that I have tried, so it maps to another address, as it should by design. I tried using MAP_FIXED as a flag to mmap() and the application crashes, as expected, since mmap() overwrites memory that is already in use.
In order for mmap() to map the binary file to the address I want, I believe that I can do some sort of advanced Android / Kotlin / gradle level compile time linking modifications in order to make sure that the area of memory (the whole page at least I imagine) that I want to mmap() to is unused when execution reaches my C++ code that calls mmap(). I don't know the android build system very well though, so I hope some Android experts can help me. I am not trying to access real physical RAM though, only address 0x22000000 in the processes virtual address space. Because of this, I believe that with some custom hackery can be done during linking to modify the areas of RAM that are assigned for program/stack/etc use. I believe I am looking for the equivalent of LD script customization for standard GCC C/C++ compiled software, and possibly some direction on how to manipulate.
I have successfully done this on a raspberry pi running raspbian via a command line C++ application, as well as an x86_64 Fedora system using an x86_64 binary blob. In both cases I got lucky that the area of memory was not in use, so mmap() succeeded and I was able to execute the code as desired.

[Firefly] [ROCKCHIP] [ITX-3588J] ITX-3588J ARM Android/Linux Dual "Deskphone" Progress

First off, I wanted to say I posted a few threads about this thing here asking questions about stuff I needed to get it working in the way I'd like and I'd want to thank you because I have made a lot of progress in getting it to be what I'd like it to be. I also don't know if this is the best forum to post this report because it's neither a question nor necessarily a tutorial but rather a summary and description of work already done so far, and especially because this device, while it sure runs Android (very well!) does not fit into any of the categories on this site neatly.
The story so far
This post concerns my experience working with the ITX-3588J, a board released just a few months ago by the Chinese manufacturer Firefly (or T-Chip Intelligent Technology Co. Ltd, based in Zhongshan) that is in the coveted mini-ITX form factor which means it can actually fit into a small-size desktop computer case and indeed has enough compute power to theoretically - and perhaps not so theoretically! - function as an honest desktop system with an ARM processor: namely the - also very new - Rockchip RK3588 system-on-a-chip.
About two months ago, I was looking into acquiring a new kind of computer to replace my somewhat longer on the tooth x86 machine that would be compact, low-power, and easy to transport while also being a fully capable desktop. And I certainly didn't want Apple. I had seen some very small form x86 desktops before, but I also knew there were many boards - like Raspberry Pi - that featured the ARM processor. Not content with the Pi, which is still very weak for this application at least when compared against modern software, I wanted to see if there was something else by now in a similar vein, and when I saw this board I thought it was an amazing option, esp. given I have not yet found a peer. Many ARM single-board devices exist but this is the only one I've found so far that looks to be in a proper desktop form factor and sporting a processor powerful enough to work at that level.
So I got the board, a case, and - noting it had SATA ports - a cheap 250 GB SSD, and put it all together ... and fired it up! And to my surprise, it booted up Android! Which was a real shocker because I generally thought this'd be like another PC board, not having had much experience with this ecosystem beyond phones, so that it would just give the usual "OS not found" stuff. Nope - pre-loaded on the board. Very minimal, very bare-bones though, not even the Google Play and similar essentials required for a usable Android experience. Yet with the little bit I had, I couldn't help but notice it was extremely fluid, responsive, and snappy, moreso than my aging 2018 era x86 box. Moreover, it was very, very interesting (and exciting!) to see Android booted onto a full-size monitor screen like Linux or Microsoft Windows - and actually and surprisingly, to see that it didn't look and feel all that bad!
However, of course, I wanted more. First, I wanted a fully-featured installation of Android. Second, I wanted to run Linux on it - especially given that, a short while later, I found that the board manufacturers were offering a stock Ubuntu 20.04 to be installable to it. Although, in the early stages, I didn't know how to do this at all, and then soon after learned how to reflash the embedded MMC chip to change the OS. And I did so, trying the Ubuntu and finding it also very performant, but not liking either that it was not quite the newest version but also more that it was mutually exclusive with Android - so far.
And that would begin a long - and at many times frustrating, especially given how much information out there is not at all tuned to a device like this being pressed into this application - learning journey toward exploring topics as diverse as how ARM processors and SoCs work under the hood, U-Boot, kernel features, the Firefly-Rockchip developer kit - and having to essentially single-handedly discover many of that kit's ins and outs given there was pretty much no documentation - and more, ultimately leading to where I've got it to now.
What it can do at this point
And that is, right now, I have it sitting here, loaded up with the stock Android 12 and Ubuntu 20.04 - with the former on the eMMC and the latter on the SSD hard drive. On the Android side, Google Play is now loaded and functional, though Google Chrome is not (it crashes with a "Telephony is null" exception for some reason, which seems to suggest for some reason it's trying to act like it's on a phone but isn't). Zoom - an app that I really, really wanted to have (and why I wanted to keep Android around on it) - works and works smoother and cleaner than my 2018 x86 Linux clunker. On the Ubuntu side, though, things are not yet coming - mostly because of seeming inability to use U-Boot to boot from the SSD. I managed to install GRUB, and given that Firefly's generous board SDK provides the full U-Boot source code was able to recompile it with the necessary "bootefi" command enabled which is not present in stock, but nonetheless alas this U-Boot seems to have its SATA support bugged or incomplete, because it would crash immediately upon trying to initialize that subsystem.
Where I'd like to go with it
Obviously, full dual boot of Android and Ubuntu, so getting U-Boot to boot the GRUB resident on the hard drive, is the biggest issue so far, and that means investigating whatever is the problem (or not?) in its SATA subsystem. Getting Google Chrome working on Android is another important step. Moreover - though it would cost extra money that I do not have right now - there's the very interesting possibility, owing to the fact that it has a built in M.2 slot on the board, and alluded to in the title - that the device could be made to act as a cell phone. And finally, the possibility of upgrading to a newer version of Ubuntu (ideally 22.04) - however from what I know so far, it looks like this will have to wait because the stock Linux kernels do not currently support the RK3588 fully - though I'd suggest the Linux kernel developers really should take a look at the SDK that came with this thing because it has lots of code in it including for the kernel, all under GPL.
Final note
One of the most interesting things I've learned from this project, and mentioned earlier, is just how well Android seems to work as a desktop OS. While there have apparently been some attempts to port it to x86, this is perhaps one of the first devices that is desktop-workable and which runs it natively. And one of the things I find that's nice about it is that ironically, because all the apps are designed for small screens, when they are run on a very big screen (and this monitor is not "very big" even by today's monitor standards, being a used and earlier LCD type), they are extremely easy on the eyes and have minimal UI clutter when compared to a typical desktop app on most Linux WMs and on MS Windows.
If you want to know more about the details, or anything else, feel free to ask any questions you might have!

UPDATE:
I believe I may have found an easier way to dual-boot Linux with Android, and that consists of configuring a custom ROM that will put both kernels, and GRUB, on the board's eMMC, while the rootfs for both OSes is placed on the hard disk. Will be seeing how it works.

UPDATE:
I have almost completed the custom ROM! I have now both Android and at least the base system for Ubuntu 20.04 (Kernel 5.10.66) bootable with Android now storing user data on the hard drive; though I'm still running into some hardware initialization issues in the latter that are keeping me from actually installing the desktop system. With regard to the Ubuntu system, there is some interesting issue in that for some reason the provided SDK kernel, which I had to rebuild, seems to build more Android-like because it wants to look in "/vendor" for some things related seemingly to the networking facilities, and it is possible this is preventing me from bringing up wifi, which I need in order to download the rest of the system.
But lots of progress overall - it seems that a full-fledged ARM desktop running simultaneously Android and Ubuntu is within reach to be wrung from this board!

Ignore my request for an update in another post. Seems you like you moving along. I don't need dual boot, just a working Android 12 with GPlay and Chrome. Did you get Chrome to work?

mebalzer said:
Ignore my request for an update in another post. Seems you like you moving along. I don't need dual boot, just a working Android 12 with GPlay and Chrome. Did you get Chrome to work?
Click to expand...
Click to collapse
Thanks. Yeah, I want to say that I have pretty successfully gotten Android 12 working on it for sure, but Ubuntu is proving much more difficult due to graphics support issues, and I'm not sure if it will be possible until RK3588 is supported in the mainline Linux kernel tree which is still something under development. And yes! I got Chrome to work Everything works, actually - it's great as an Android system, though obviously Android is kinda funny to use as a desktop OS. I am wondering if I can't get a "pseudo" Linux using something like Linux Deploy in lieu of running it natively, at least until the kernel development catches up with this new processor.
(FWIW, I'm posting this post from that machine while it is running A12. )
Good to see someone else is interested in it, though. What are you planning on using yours for?

Insofar as getting Android 12 to work w/GApps - it depends on if you want to do it purely on the eMMC or you want to also put user data on an attached hard drive like I did. In either case, the best option, I feel, is to create a custom ROM - I could provide custom ROMs for it for download, but don't know because of Google's licensing conditions around the GApps and have heard of people getting in trouble with Google for distributing custom ROMs for phones that have GApps in them. You basically need to unpack the stock Android image, unpack the "super.img", then load the apps from a package like NikGApps into the "product" partition (NOT "oem" - that was a big mistake), then repack everything and flash to the eMMC again. You will need the board SDK from Firefly for all this as it has the custom ROM-packing and flashing tools.
Alternatively, it is possible to manually install the NikGApps GApps using the Android console - as it's a fully unlocked system, obtaining root access is trivial: just put it into Developer mode and you will find the root access in the "Developer options..." menu under "System".

Shimmy99 said:
Insofar as getting Android 12 to work w/GApps - it depends on if you want to do it purely on the eMMC or you want to also put user data on an attached hard drive like I did. In either case, the best option, I feel, is to create a custom ROM - I could provide custom ROMs for it for download, but don't know because of Google's licensing conditions around the GApps and have heard of people getting in trouble with Google for distributing custom ROMs for phones that have GApps in them. You basically need to unpack the stock Android image, unpack the "super.img", then load the apps from a package like NikGApps into the "product" partition (NOT "oem" - that was a big mistake), then repack everything and flash to the eMMC again. You will need the board SDK from Firefly for all this as it has the custom ROM-packing and flashing tools.
Alternatively, it is possible to manually install the NikGApps GApps using the Android console - as it's a fully unlocked system, obtaining root access is trivial: just put it into Developer mode and you will find the root access in the "Developer options..." menu under "System".
Click to expand...
Click to collapse
Thanks I will keep this in mind. See my reply to you other reply on another post as well.

I would to run gplay as well please send me instruction the nikapps github doesnt say nothing