Does anyone know of any VirtualBox Android Emulator that has Marketplace?
Thanks!
Oh, I forgot to add "that's free" and not the $50 that some cheeky bastards are trying to charge for a thing called AndroidVM!
iridium21 said:
Does anyone know of any VirtualBox Android Emulator that has Marketplace?
Thanks!
Oh, I forgot to add "that's free" and not the $50 that some cheeky bastards are trying to charge for a thing called AndroidVM!
Click to expand...
Click to collapse
Android doesn't just load up and run on a PC. It's a source code project that a real developer has to spend time porting from platform to platform, unless you want to run it from a runtime built from the SDK. To do that requires an underlying OS, like Windows, Linux a MAC - something capable of running the SDK.
Since, VMware is emulating a PC, then in order to run as a real virtual machine, android needs to be pretty much ported to a PC. Since Android is built on a Linux kernel, it's not impossible, but geese - why? That said, it's bound to show up on an Intel compatible tablet at some point, if it hasn't already.
attn1 said:
Android doesn't just load up and run on a PC. It's a source code project that a real developer has to spend time porting from platform to platform, unless you want to run it from a runtime built from the SDK. To do that requires an underlying OS, like Windows, Linux a MAC - something capable of running the SDK.
Since, VMware is emulating a PC, then in order to run as a real virtual machine, android needs to be pretty much ported to a PC. Since Android is built on a Linux kernel, it's not impossible, but geese - why? That said, it's bound to show up on an Intel compatible tablet at some point, if it hasn't already.
Click to expand...
Click to collapse
I'm already running Android under Virtualbox - I just wondered if there's a version for VB that has Marketplace.
attn1 said:
Android doesn't just load up and run on a PC. It's a source code project that a real developer has to spend time porting from platform to platform, unless you want to run it from a runtime built from the SDK. To do that requires an underlying OS, like Windows, Linux a MAC - something capable of running the SDK.
Since, VMware is emulating a PC, then in order to run as a real virtual machine, android needs to be pretty much ported to a PC. Since Android is built on a Linux kernel, it's not impossible, but geese - why? That said, it's bound to show up on an Intel compatible tablet at some point, if it hasn't already.
Click to expand...
Click to collapse
Wow. So much complete and utter wrong in one post... I've been running Android under a virtual machine for quite a while...
There is an x86 version of Android available at androidx86.org
It will definitely run under Virtual Box or any other virtualization software package. It's Android 1.6 by the way, and you will have to perform some geek-like activities to simulate an SD-card to install appz.
Big question is whether an ARM-device version of Android would work in a normal VM emulator (not talking about Bochs and stuff).
FloatingFatMan said:
Wow. So much complete and utter wrong in one post... I've been running Android under a virtual machine for quite a while...
Click to expand...
Click to collapse
Well, since I hadn't heard of a port to x86, I was certainly wrong about that, which makes the rest of the post moot, but not wrong. In any event, I stand corrected.
sorry to add a flame of any kind but this
"Since, VMware is emulating a PC, then in order to run as a real virtual machine, android needs to be pretty much ported to a PC. Since Android is built on a Linux kernel, it's not impossible, but geese - why? That said, it's bound to show up on an Intel compatible tablet at some point, if it hasn't already."
is totally wrong.
Virtual machines virtualise the hardware of your machine (bad explanation I KNOW). if you have a PowerPC you can only emulate PowerPC (Mac for those that dont know) and intel/amd chips are things like x86 then theres smaller devices like ARM. my point is that if you have a Intel/amd box you can only emulate x86 O/S. however if you have a netbook with a version of linux or windows built on arm arch then u could prob get away with the original android if you are running normal x86 then u require android that has been built from source on x86.
this made me laugh
"Since Android is built on a Linux kernel, it's not impossible"
all i can say is what??
anyway back to the point... to run android on a x86 box u need x86 android
The problem with getting the Market to work is simply that the GApps are currently only available in a compiled for ARM version. period. that's the answer you wanted to hear i guess.
@others: stop OTing please...
hvc123 said:
sorry to add a flame of any kind but this
"Since, VMware is emulating a PC, then in order to run as a real virtual machine, android needs to be pretty much ported to a PC. Since Android is built on a Linux kernel, it's not impossible, but geese - why? That said, it's bound to show up on an Intel compatible tablet at some point, if it hasn't already."
is totally wrong.
Virtual machines virtualise the hardware of your machine (bad explanation I KNOW). if you have a PowerPC you can only emulate PowerPC (Mac for those that dont know) and intel/amd chips are things like x86 then theres smaller devices like ARM. my point is that if you have a Intel/amd box you can only emulate x86 O/S. however if you have a netbook with a version of linux or windows built on arm arch then u could prob get away with the original android if you are running normal x86 then u require android that has been built from source on x86.
this made me laugh
"Since Android is built on a Linux kernel, it's not impossible"
all i can say is what??
anyway back to the point... to run android on a x86 box u need x86 android
Click to expand...
Click to collapse
VMware and Virtualbox emulate PC hardware. Since Android runs on a Linux kernel, and Linux was originally developed for an x86 PC, it follows that a port of Android could be done for a PC. Since this was not a generic discussion about virtual machines but a specific discussion about PC emulation, I don't see where the argument is.
PC = x86 and it's successors. You said I was totally wrong and then pretty much made my case. The only point I missed is that the work had already been done. To run Android in a x86 (PC) VM, you'll need an X86 (PC) compatible version of Android - right - what I said.
Right... Ok, now does anyone know the answer to the original question?
the_fish said:
The problem with getting the Market to work is simply that the GApps are currently only available in a compiled for ARM version. period. that's the answer you wanted to hear i guess.
@others: stop OTing please...
Click to expand...
Click to collapse
OP should read your thread.
arctu said:
OP should read your thread.
Click to expand...
Click to collapse
I have
Supposedly, these guys have Android with Marketplace for VirtualBox:
http://www.androidvm.com/home
So it must be able to be done - the only problem is that it's $49.95!
deleted
zgornz said:
They state they are running Ubuntu in a VM, then installed the Android emulator in Ubuntu, then the android emulator is setup to have the Marketplace. The android emulator is doing the ARM emulation.
I think using qemu User Mode emulation it might be possible to actually launch the Marketplace and apps via android-x86 without using a phone emulator. Not sure it would be that valuable, but it would allow lots more apps on a netbook running Android.
Click to expand...
Click to collapse
I imagine it would be a mess to get a touch screen working in android running on an emulator.
I read reviews on androidx86 booted (not emulated) on a few netbooks that ran great and very responsive..I also read one on a touch screen comp that worked fine..they claim all apps work-minus gapps obviously.
I plan on trying this on my Toshiba nb205 netbook today and can post a review if anyone is interested..
Sent from my Nexus One using the XDA mobile application powered by Tapatalk
A review would sure be appreciated. More knowledge is always better.
Just a quick follow up, I tried out the Androidx86 on my netbook this weekend, both booted off the usb and installed on the hd..it runs..nothing spectacular and slightly dissappointing. You still only have a 4x4 screen and the Marketplace is entirely different, very small selection of "blah" apps..none of my favorite android apps anyways-facebook,twitter,gmail..not really any widgets either. Lastly, you need to use an external mouse..the touchpad just moves the background but gives you no pointer (could be a hardware compatability issue tho)..
On the positive side, the internet was very fast and resume time was almost instantanious..not really any major bugs, just nothing too special..
This method works with 1.6 as originally described here:
link-> forum.xda-developers.com/showthread.php?t=529170
I got it to run with the signed-dream_devphone_userdebug-img-14721.zip image from HTC for the developer phone.
link-> developer.htc.com/adp.html
I replaced the android-sdk-windows\add-ons\google_apis-4_r02\images\system.img with the one from the signed-dream_devphone_userdebug-img-14721.zip
(you should backup the original system.ini)
I then used the Android SDK GUI interface to create a Google API Level 4 machine.
I did not need to install the marketenabler.apk, as described in the original thread.
It boots up like a new Dev Phone, it behaves like there is a valid SIM and working data connection.
CTRL-F11 rotates the screen (slide out keyboard).
I have only installed a few free apps (K9 mail) but they seem to work fine.
I can't post links so copy, and paste them.
It would be trivial to create an Ubuntu virtual machine and then install the Android SDK inside of it and modify the system.img. Installing the SDK on your own machine probably takes less space and resources then running it inside another VM.
attn1 said:
Well, since I hadn't heard of a port to x86, I was certainly wrong about that, which makes the rest of the post moot, but not wrong. In any event, I stand corrected.
Click to expand...
Click to collapse
Updated, not corrected.
Yes, you were absolutely correct except for being out of date, because that process you described has already taken place as others have now pointed out.
To the person who said he was wrong, actually, no.
Android as it stands on the phone, is an ARM system compiled in ARM machine code. Android apps are hardware/platform agnostic but the operating system is not, it does have to be ported and recompiled for any different hardware system. That being said, it seems that most of that work is finished, ala androidx86.org
Cheers,
Rob
x86 Android Market
I have been reading a bit. It seems that it is possible to have Gapps installed for x86.
Froyo, people have been using Cyanogen 6 Gapps for Tegra.
Android x86 launched their Gingerbread version not long ago. It would not surprise me if Cyanogen 7 Gapps worked with it. Different devices used different versions and now there is just one version for all. It should be possible to run VM from the desktop.
NDK dependent Apps: in theory, it may be possible taking the apk using android apk tool, x86 NDK from the x86 build and rebuild it for x86 code.
I will be playing with an old EEE900 and see how this goes sooon.
i just want to know that why android operating system does not work directly in mobile devices
why there is need of development in it to use in all diffrent phones?
why it cant work directly like windows in pc does
and other question all others like bada os, symbien and apple os they all need they also need development or we can use them directly
if sumone didnt understand my question i will explain more
for further explanation>
windows we can install directly in any pc of any company or assembled
but android need development and designed for a seprate product of a specific brand
why?
no1 is intrestd in answring these questions ?
You are just kidding here right?
/Pun intended.
For example
[1] ....
[n] Windows has the complete set of drivers
[n+1] The manufacturer delivers the driver
Fundamentally, you're misunderstanding the situation. Windows does not run on any computer you can throw together. It runs on any computer that you can throw together that matches the evolving, de facto standard that started as the IBM PC.
It won't run on a SPARC Station or a 68k Mac or an IBM 360 or a Wii or a PS3 or, well, a HTC Vision.
Similarly, Android will run on any PC, er phone, er tablet, er, well computer that is basically the same as an existing Android device. The vast majority of the custom development that is, strictly-speaking, necessary for a new device amounts to device drivers. Now, most manufacturers do a lot on top of that to distinguish their product. That's where Sense and MotoBlur and such-like come into play.
A further complication is that storage space and memory are at a heavy premium on these devices. So, it is infeasible to include the incredible variety of drivers and other hardware support that makes a typical Windows or Linux install need several GBs.
Back in the day, when dinosaurs roamed the earth and there were only a handful of PC makers in the world, similar customization was needed. My first PC came with a manufacturer-custom version of DOS 2.1 and Windows 1.1. Is wasn't until at least DOS 3.x (maybe 4.x, that was a long time ago) that a vanilla MS copy had a chance of working. Even then, most peripherals *needed* a custom driver to be used at all. My first mouse is an example. Only way to use it was the Genius Mouse drivers that came with it.
thanks for ur answers guys
Hello gents and ladies,
Since the announcement that Canonical made on making Ubuntu on Android a release for OEMs to put on their devices, there has been quite a stir and interest on when we are getting to get this on our phones. Sadly, while the distro of Ubuntu is open-sourced, the programs that were created to achieve this method are not available to the public due to Canonical outsourcing the work to a 3rd party company.
Some users here may already say that we have Ubuntu on our phones but the method that is most commonly used by the community is to load up a virtual environment or Chroot inside of Android then remote into the interface via a VNC connection app. While this does work, it is a pretty sloppy method that is resource intensive and does not benefit from any hardware acceleration for the Linux desktop environment that is used. Plus, there is no way to pipe audio thru a VNC connection so using any audio/video programs in VNC is pointless.
Lastly, Ubuntu on Android is actually nothing new to the world of Android, as its been around for about a year and a half. It came in the form called Webtop that Motorola had launched on their Atrix/Bionic/RAZR lineup of phones. Webtop is essentially a stripped down version of Ubuntu with a lot of Linux tools taken out along with a very limited desktop environment. Webtop does everything that Ubuntu on Android does but in a neutered manner but there are different groups on each phone that have accomplished bringing back many of the linux tools that were taken out. Check out the thread below to see what I mean.
http://forum.xda-developers.com/showthread.php?t=1397583
It is believed that the same methods and tools that are present in Webtop are the same ones being used by Ubuntu on Android and possibly made by the same company. This can be seen in the demo video of Ubuntu on Android where the demonstrator had replaced the Webtop distro with a full Ubuntu 12.04 distro on a Motorola Atrix 2. So to debunk the myth that Ubuntu on Android can be easily loaded up on a phone as shown on video, no cause it was initially was setup with the required framework and partition space to load Ubuntu on Android even before Canonical announced Ubuntu on Android.
With all that is said, Canonical is targeted OEMs and Carriers to launch their Ubuntu on Android on select model phones and probably will not release the necessary tools as open-source code so the development community can compile their own working Ubuntu on Android. Now, all hope is not lost because some of the work has already been done but needs to come together into a package that can be ported from one phone to another.
Here are different parts that are needed:
1) Ubuntu image
There are many working images out there that run in a chroot environment but there is one universal image that is being implemented that is made by zacthespack that works on a variety of different devices - See attached thread
http://forum.xda-developers.com/showthread.php?t=1467811
2) X Server Port
Instead of using a VNC client and server model which is very resource intensive and does not benefit from GPU acceleration/Framebuffer. Using a X Server windows management system like they do on home PCs and laptop will greatly increase speed and functionality of a Linux distro opposed to VNC. This is how Webtop on the Motorola phones work is by using a port of X Server which pipes the display out to the HDMI port to be used with the Laptop dock or home dock. There is a group at AndroiX.org that is working on a port of X Server for Android that is looking very promising so hopefully anybody that can contribute to project to speed it up as it is the most crucial part for Linux in Android.
3) Sound
The biggest drawback of VNC is the lack of any sound processing which can be very annoying when trying to watch any videos or listen to sound clips on the web. What they are using on Webtop and Ubuntu on Android is a custom compiled version of PulseAudio module to pipe audio thru Android's audio manager system. No projects have yet been started on this so if anybody knows of one, feel free to post a link.
4) Android in Window
As demo'ed in the video and on Webtop, you have the ability to see whats on your Android display but in a window within Ubuntu when Webtop/Ubuntu on Android is engaged. This is a cool feature that maybe a X client app within android that pipes the display to a window in Ubuntu or maybe VNC client/server scenario. This is not really necessary to Linux in Android but non the less a cool feature to have.
5) Contacts/Text messages/Call logs
This is more shown in Ubuntu on Android opposed to Webtop where in Ubuntu mode, you can look at your Contacts or call logs in a program as opposed a Android view in a window. They also demo'ed a special program in Ubuntu to where you can send/receive text messages in a interface designed for Unity. They accomplished this by using a server application in Android, more commonly known as Motorola Phone Portal, that can relay information from the phone to applets inside of Webtop/Ubuntu on Android using a web interface API on localhost:8080 or on a remote computer on the same network. Like I said before, not really necessary but another cool function to have.
All and all, this pretty much sums up all the different parts for a project like this to take place. I am in no way a seasoned developer, just a person throwing out concepts that I have learned and done myself on the Bionic Webtop phone which hopefully some skilled individuals can run with as I am no Linux expert by any means. Anywho, let me know what you guys think about this and what can be improved.
Ubuntu on arm.
I've been looking into the development of something like this and have found a few resources that may prove beneficial:
Linux 4 Tegra (nVidia)
System Requirements
Host PC running Ubuntu Linux version 9.04 or higher.
Tegra Linux Driver Package providing a kernel image, bootloader, NVIDIA drivers, and flashing utilities. For more information, see the Release Notes.
Sample filesystem (example provided derived from Ubuntu 12.04)
Click to expand...
Click to collapse
Please note that nVidia currently provides driver packages for each model of the Tegra (Tegra 2 and 3).
As well as:
Ubuntu on Smartphones
Now. I've been playing with both an Ubuntu and Debian chroot and have ran into the issues you speak about (in a chroot with only vnc support is very limited, no sound, no camera, etc.) and would like the ability to dual boot at least.
[Q&A] Ubuntu on the Transformer (eMMC install) (xda-developers)
Basically, the creator of this thread is working from another dev's work to get ubuntu running on an Asus eeePad.
Hi Folks.
With both a Zune HD and WP7 devices not supported via USB conenction to a Surface RT, I was thinking there had to be a way to tweak/re-write the ZuneHD / Zune driver files to allow them to be installed on the Surface RT...The ZuneHD is an ARM based device running Windows Embedded - and RT is an evolution of Windows CE you might say.
If so, the earlier regedit hack to allow the WP7 (or ZuneHD) to connect as a USB mass storage device would hopefully be possible, without the full ARM recompile of the Zune software (a near impossible task).
It's ridiculous that pre WP8 devices cannot even be connected via USB to facilitate file transfers "non-cloud" way.....
I tried manually updating drivers on the Surface RT with my ZuneHD connected - pointing at the Zune 4.7 drivers, and it confirmed that they were not ARM compatible.
Cheers,
Sheeds.
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all? You act like you have some idea what an instruction set architecture is, but you say this. If I ran this entire message through a translator to Finnish and then ROT-13'd it, you'd probably have a better chance of understanding the post than of managing to get the existing x86 Zune driver working on RT without a full re-write plus an additional hack to bypass driver signing. The Zune driver isn't exactly open-source... binary emulation *might* work at some point, but it's not practical for a kernel-mode driver (signature checks or not).
There is not, and never was, a hack to allow Zune-like devices to connect using UMS. The hack you're referring to merely un-hid the MTPZ (Media Transfer Protocol, Zune) devices from Windows Explorer. MTP(Z or not) and UMS are not at all the same thing, although they can sometimes be used for some of the same purposes.
We'd have a much better chance of getting Zune to run on RT, actually. That's "just" a matter of emulating an x64 machine for it to run on and passing its system calls through to the real OS and back again. Won't do any good for this use case without the driver, of course.
What does it matter that RT and CE run on the same ISA? The driver that we need is x86/x64 only.
There is basically nothing in common between CE and NT, aside from the fact that they're both portable operating systems from Microsoft and both implement some large portion of the Win32 API. Claiming that "RT is an evolution of Windows CE" is laughably wrong. They probably have less in common than Windows 95 (9x kernel, partially based on Win16 code) and Windows 8 (NT kernel, completely different project that contains no portions of DOS/Win16 except the re-implementation of the shell in NTVDM) - at least Win8 can run (many) Win95 apps. CE is at least as different from each of those as they are from eachother.
At this point, I'd guess that the most practical way to connect Zune on Windows RT would be the following:
a) Use a full x86-machine emulator (Bochs or QEMU, for example).
b) Use one that does JIT and/or dynamic recompilation, so the performance isn't abysmal (not sure what qualifies here...)
c) Install XP on it (no point targeting something newer).
d) Install Zune on the emulated XP.
e) Forward the tablet's USB port to the emulated machine's USB port (not sure if anybody has the ability to do this... currently, we can't even get networking in the emulated machine).
Good luck with that! I actually mean that quite seriously, I have a WP7 device myself and it annoys me that my Surface and it can't communicate except over Bluetooth (and I had to hack the phone to get that much).
GoodDayToDie said:
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all?QUOTE]
LOL - Thanks for the informative reply Luckily I have no delusions of grandeur over the fact that I am A) not a Developer and B) can't code past "hello world"
I was coming from the angle of the old registry hack for WP7 which allowed your phone to work as a USB mass storage file by a simple change via regedit to one of the registry strings associated to the Zune Driver....Certainly ignorant of the finer (and even the coarser) detail of your reply...so thanks for the explanation.
I added a MS Answers post asking why Microsoft cannot provide USB device connection for legacy WP7 and ZuneHD units with Windows RT. Be interesting to see what they or their MVP's reply to this, if at all.
Cheers.
Click to expand...
Click to collapse
Yeah.. asking MS to support the devices is definitely the best approach. We might manage to make a user-mode connection to them using some third-party software talking directly to the USB port on sufficiently hacked RT devices, but that's about the best we'll get.
Also, I really with people would stop calling it a "USB Mass Storage" hack. I've posted to that effect in the relevant forums that I can find, too. This is not now, never was, and (short of custom ROMs or special bootloader modes) never will be a UMS interface to Zune-like devices. The device literally doesn't support it. Please don't confuse Media Transfer Protocol for USB Mass Storage. They are *not* the same. For example, those nicely named music files you see when using the "UMS" hack for WP7/Zune? *THEY DO NOT EXIST* anywhere on the device's filesystem. True, there are files containing the same binary data, but they have names like "2D.mp3" and are stored in a filesystem structure designed to make referencing them in a database faster. MTP exposes a hierarchical storage system (which may, coincidentally, mirror the filesystem although it does not do so on Zune-like devices), but it does *NOT* expose the filesystem/storage (which is what UMS does).
I decided to create a new thread for this, because I have confirmed that I now have my device rooted via KingRoot and have installed BusyBox, so the thread title of my previous thread is no longer relevant to my situation.
Anyway, I have a Chinese netbook thing with a keyboard and touchpad, but no touchscreen, GPS, or SIM card functionality. It was cheap and don't have anything essential on the device, so I'm not afraid to brick it if there's risk involved.
Most guides that explain how to get Linux working on Android devices only explain how to access Linux indirectly via a VNC viewer or terminal running on Android, which is not what I want because I don't have enough RAM to run X on top of Android and a VNC viewer. There's too much overhead. I want Linux running on the bare hardware so that I can compile/run native ARM code and use applications actually designed for a mouse/keyboard rather than a touchscreen.
I'm trying to figure out what that would take. Can my device be booted from an SD card so that I can keep Android and boot into Linux by inserting the SD card? Or do I need to flash the "BIOS" and wipe everything out in order to achieve this? If so, what do I need to flash to get a Debian ARM distribution working on such a device, and how do I do it? Ideally, I'd like to be able to dual boot rather than be limited to one OS, but I'm willing to replace Android if it's required.
I'm not sure if I'm posting in the right place, but the problem is that most of the more specific forums on this site involve knowing the exact brand-name and model of the device, and I only know the Chipset and specs of my system. I can't even post pictures of the device or screenshots of application output because I don't have enough posts yet.
Basically, the core of the system is GA-1311F, WM8880. It has a 13.3" screen, 1GB of RAM, 8GB of Storage, Cortex A9 @ 1.5GHz, and Mali 400MP2 Graphics. It has two USB type-A ports, a Headphone and Microphone port, an SD card slot, an HDMI port, and an Ethernet port that I suspect may be powered by a RealTek 8192 chipset of some kind. There's also Bluetooth and Wi-Fi. When I run a terminal and look around at the configuration, I see the acronym WMT all over the place, but I don't know what it means. It's currently running Android Jelly Bean.
I haven't found a lot of information about my specific device, as there is no manufacturer listed aside from VIA and WonderMedia, although they only make the chipset and not the actual devices.
Thread closed / Duplicate