Infeasible
Status Update
Comments
ss...@google.com <ss...@google.com>
ss...@google.com <ss...@google.com>
ea...@google.com <ea...@google.com> #2
a concerning line is:
emulator: WARNING: Host CPU is missing the following feature(s) required for x86 emulation: SSSE3
what is the CPU in your computer?
The new emulator system requirements are posted here:
http://tools.android.com/tech-docs/emulator
emulator: WARNING: Host CPU is missing the following feature(s) required for x86 emulation: SSSE3
what is the CPU in your computer?
The new emulator system requirements are posted here:
th...@gmail.com <th...@gmail.com> #3
The processor is an AMD Phenom II x6 1075T, and it has AMD-V, as required by the new Android emulator in Linux (please see this link for more info on this CPU : http://www.cpu-world.com/CPUs/K10/AMD-Phenom%20II%20X6%201075T%20-%20HDT75TFBK6DGR.html )
It does not have SSSE3, but I don't see it as a requirement in the Android emulator specs.
It does not have SSSE3, but I don't see it as a requirement in the Android emulator specs.
jl...@gmail.com <jl...@gmail.com> #4
[Comment deleted]
jl...@gmail.com <jl...@gmail.com> #5
The same for me.
I have an AMD Phenom II x6 1090T running Ubuntu 14.04 64 bit, which doesn't support SSSE3. API 22 x86 works. API 23 x86 doesn't work (i.e. emulator starts but its screen keeps black).
I have an AMD Phenom II x6 1090T running Ubuntu 14.04 64 bit, which doesn't support SSSE3. API 22 x86 works. API 23 x86 doesn't work (i.e. emulator starts but its screen keeps black).
a....@gmail.com <a....@gmail.com> #6
The same for me.
I have an AMD Phenom II X6 1055T running Ubuntu 14.04 64 bit. API 22 x86 works. API 23 x86 doesn't work (i.e. emulator starts but its screen keeps black).
This is happening for Platform N too.
I have an AMD Phenom II X6 1055T running Ubuntu 14.04 64 bit. API 22 x86 works. API 23 x86 doesn't work (i.e. emulator starts but its screen keeps black).
This is happening for Platform N too.
fl...@gmail.com <fl...@gmail.com> #7
The same for me :(
AMD Phenom(tm) II X4 945 Processor it has no ssse3. Running Arch Linux. API 23 gives a black screen. The arm images do work in a paint drying kind of way. API 23 doesn't work on Genymotion either
Older images work pretty good.
AMD Phenom(tm) II X4 945 Processor it has no ssse3. Running Arch Linux. API 23 gives a black screen. The arm images do work in a paint drying kind of way. API 23 doesn't work on Genymotion either
Older images work pretty good.
ea...@google.com <ea...@google.com>
rp...@gmail.com <rp...@gmail.com> #8
Perhaps similar issue - emulator with blank screen for x86 emulation for all tested apis - 16,21,23
OS: slackware 64 14.1 on AMD Phenom II x6 1090T
Android SDK: 23.0.5, 24.3.4 or 24.4.1 , Note 25.1.3 does not work as it depends from QT5.
From command line I could get screen with text "ANDROID" and that's all.
Last test was "/opt/android/sdk_r24.4.1/tools/emulator64-x86 -avd api21.v501-cpu.x86 -debug-all -noaudio -nocache" and result is similar as first post plus repeating errors:
emulator: Error while connecting to socket '127.0.0.1:1970 ': 111 -> Connection refused
OS: slackware 64 14.1 on AMD Phenom II x6 1090T
Android SDK: 23.0.5, 24.3.4 or 24.4.1 , Note 25.1.3 does not work as it depends from QT5.
From command line I could get screen with text "ANDROID" and that's all.
Last test was "/opt/android/sdk_r24.4.1/tools/emulator64-x86 -avd api21.v501-cpu.x86 -debug-all -noaudio -nocache" and result is similar as first post plus repeating errors:
emulator: Error while connecting to socket '
th...@gmail.com <th...@gmail.com> #9
Any news on this issue ? It happens on N as well
ne...@gmail.com <ne...@gmail.com> #10
Same problem.
CPU - Athlon x64 X2 3600+.
RAM: 8GB
OS: Manjaro x64
All x86 images work with same SSSSE3 warning, except API 23.
Just black screen in AVD emulator.
Genymotion API 23 does work here on same computer.
CPU - Athlon x64 X2 3600+.
RAM: 8GB
OS: Manjaro x64
All x86 images work with same SSSSE3 warning, except API 23.
Just black screen in AVD emulator.
Genymotion API 23 does work here on same computer.
di...@gmail.com <di...@gmail.com> #11
Same problem with Quad-Core AMD Opteron(tm) Processor 2354
sm...@gmail.com <sm...@gmail.com> #12
Same problem.
CPU: AMD Phenom II X4 955 Processor
RAM: 8 GB
OS: Linux Fedora 24 x86_64
All Android images woks with SSSE3 warning, except API 23 x86 and API 24 x86.
API 22 x86 and below works fine. API 23 x86 and API 24 x86 doesn't work (emulator
starts but it screens keeps black.
CPU: AMD Phenom II X4 955 Processor
RAM: 8 GB
OS: Linux Fedora 24 x86_64
All Android images woks with SSSE3 warning, except API 23 x86 and API 24 x86.
API 22 x86 and below works fine. API 23 x86 and API 24 x86 doesn't work (emulator
starts but it screens keeps black.
ea...@google.com <ea...@google.com>
hf...@gmail.com <hf...@gmail.com> #13
Same issue with
- AMD Athlon II X2 250 Processor
- Linux Fedora 22 x64
- API 23 and 24
- AMD Athlon II X2 250 Processor
- Linux Fedora 22 x64
- API 23 and 24
pe...@gmail.com <pe...@gmail.com> #14
Same problem affecting me in this new year of 2017...
To be specific:
API 22 x86 image works fine.
API 23+ x86 images give black screen.
- AMD Phenom II X4 955 Processor
- RAM: 8GB
- OS: Arch-based (Antergos)
To be specific:
API 22 x86 image works fine.
API 23+ x86 images give black screen.
- AMD Phenom II X4 955 Processor
- RAM: 8GB
- OS: Arch-based (Antergos)
al...@gmail.com <al...@gmail.com> #15
I am having the same problem , tried everything nothing seems working
CPU : AMD A4-3330MX APU with Radeon(tm) HD Graphics
OS : Ubuntu 17.04
CPU : AMD A4-3330MX APU with Radeon(tm) HD Graphics
OS : Ubuntu 17.04
ma...@gmail.com <ma...@gmail.com> #16
I am seeing the same problem on an ASUS M5 A88-V EVO with an AMD Phenom II 1045T on 64 bit Ubuntu 17.04. I tried API 22-25 and the only one that actually started was 22. All of the rest brought up the device and skin but the screen stayed black and the emulator never seemed to actually start Android. It was very quick to start and seemed to work well with 22 though.
Android Studio 2.3.3
Android Studio 2.3.3
m....@gmail.com <m....@gmail.com> #17
Same problem - also with a Phenom II and in an ASUS M5A97 EVO. Message is:
emulator: WARNING: Host CPU is missing the following feature(s) required for x86 emulation: SSSE3
It is certainly true, the Phenom II doesn't support SSSE3. But this wasn't required previously.
Also tried
/usr/local/toolset/android-sdk/tools/emulator -avd 'Nexus_5X_API_26' -no-accel
But that failed to start at all. I might be prepared to buy an AMD FX processor with SSSE3 if that would solve the problem. The only practical solution for now is to use a real phone for testing (AMD emulation is too slow).
emulator: WARNING: Host CPU is missing the following feature(s) required for x86 emulation: SSSE3
It is certainly true, the Phenom II doesn't support SSSE3. But this wasn't required previously.
Also tried
/usr/local/toolset/android-sdk/tools/emulator -avd 'Nexus_5X_API_26' -no-accel
But that failed to start at all. I might be prepared to buy an AMD FX processor with SSSE3 if that would solve the problem. The only practical solution for now is to use a real phone for testing (AMD emulation is too slow).
pe...@gmail.com <pe...@gmail.com> #18
I have same issue on ubuntu, has this issue been resolved?
m....@gmail.com <m....@gmail.com> #19
Not an ideal solution, but I can confirm that replacing a Phenom II 1090t CPU with a newer FX-6300 solves the problem. I retained the ASUS M5A97 EVO motherboard - it already had the latest firmware with FX support. No other hardware changes were necessary. At least the FX-6300 is not too expensive these days.
ma...@gmail.com <ma...@gmail.com> #20
I'm really glad that you posted that. I actually have an FX 8350 that I bought a couple of months ago and still haven't installed. I'll try that. :)
hi...@gmail.com <hi...@gmail.com> #21
Google please fire the developer to whom the issue is assigned (the site unfortunately shows the mail with dots, so I can't even ping you directly). Because having the issue as simple as removing -mssse3 switch and rebuilding stuff, plus affecting everyone with AMD CPUs (since those support sse4a instead), unsolved for a year is just unacceptable.
py...@gmail.com <py...@gmail.com> #22
Yes, please fix this thing please, really annoying....
bo...@google.com <bo...@google.com> #23
#19 glad it works for you with newer model of AMD processors: we will try to make sure it keeps working.
for all the other developers that can not run emulator on your current AMD processors: thanks for your patience and for bringing this issue up.
I have talked to the tool chain people and they told me they have to require SSSE3. simply disabling SSSE3 is not doable as the tool chain
is already assuming SSSE3 support. (I tried and it still uses SSSE3 instructions anyway).
what we can do going forward is to make sure we can run emulator on the main line AMD processors on linux at least.
(HAXM only works with intel chips on mac/windows)
for all the other developers that can not run emulator on your current AMD processors: thanks for your patience and for bringing this issue up.
I have talked to the tool chain people and they told me they have to require SSSE3. simply disabling SSSE3 is not doable as the tool chain
is already assuming SSSE3 support. (I tried and it still uses SSSE3 instructions anyway).
what we can do going forward is to make sure we can run emulator on the main line AMD processors on linux at least.
(HAXM only works with intel chips on mac/windows)
hi...@gmail.com <hi...@gmail.com> #24
#23 it is easy to find where ssse3 is used in the code. In the worst case you could build it with debug information and then use objdump + grep to find it out. And I'm pretty sure there's more ways. Then you could figure out why exactly ssse3 is still there (e.g. perhaps they're using some gcc builtins), and fix it.
Beforewords, sorry for me being mean, I really don't want to tell you how to do your job. But you're working in damn Google, and this issue is α) far from being a rocket science, and β) hangs on you for a year! Do something!
Beforewords, sorry for me being mean, I really don't want to tell you how to do your job. But you're working in damn Google, and this issue is α) far from being a rocket science, and β) hangs on you for a year! Do something!
bo...@google.com <bo...@google.com> #25
#24, thanks for the tip,
it sucks that emulator does not work on certain AMD CPUs, for such a long time: many other devs are feeling the same frustration too.
changing android tool-chain is not in my control. but will definitely keep experimenting other options, and any suggestion is always welcomed.
I did talk to someone who knows a few more thing on this topic, we might try to do something else, such as just emulate the SSSE3-no idea how easy/hard that will be,
but will keep you posted.
it sucks that emulator does not work on certain AMD CPUs, for such a long time: many other devs are feeling the same frustration too.
changing android tool-chain is not in my control. but will definitely keep experimenting other options, and any suggestion is always welcomed.
I did talk to someone who knows a few more thing on this topic, we might try to do something else, such as just emulate the SSSE3-no idea how easy/hard that will be,
but will keep you posted.
hi...@gmail.com <hi...@gmail.com> #26
> changing android tool-chain is not in my control. but will definitely keep experimenting other options, and any suggestion is always welcomed.
>
>I did talk to someone who knows a few more thing on this topic, we might try to do something else, such as just emulate the SSSE3-no idea how easy/hard that will be,
Then reassign the issue to ones who are in control of the toolchain. You're sure can go as far as emulating SSSE3, but unless you already have something offhand to make this working, it's a bunch of work, you have to emulate 16 instructions. And this is even more hilarious considering how easy the direct solution — simply don't use SSSE3.
>
>I did talk to someone who knows a few more thing on this topic, we might try to do something else, such as just emulate the SSSE3-no idea how easy/hard that will be,
Then reassign the issue to ones who are in control of the toolchain. You're sure can go as far as emulating SSSE3, but unless you already have something offhand to make this working, it's a bunch of work, you have to emulate 16 instructions. And this is even more hilarious considering how easy the direct solution — simply don't use SSSE3.
bo...@google.com <bo...@google.com> #27
#26:
I already got complains from other teams (including toolchain team) that emulator image is holding them back;
The decision to update tool chain is more based on physical hardware, not based on emulator. going forward, emulation
is likely the only solution we have left with.(performance could take a hit on certain CPUs, but restricting SSSE3 usage will slow down
other CPUs that do have SSSE3).
(btw, assign this emulator specific bug to other team will keep it in unresolved longer)
I already got complains from other teams (including toolchain team) that emulator image is holding them back;
The decision to update tool chain is more based on physical hardware, not based on emulator. going forward, emulation
is likely the only solution we have left with.(performance could take a hit on certain CPUs, but restricting SSSE3 usage will slow down
other CPUs that do have SSSE3).
(btw, assign this emulator specific bug to other team will keep it in unresolved longer)
hf...@gmail.com <hf...@gmail.com> #28
It is not acceptable that SSSE3 is mandatory.
Many tools, emulators and visualization solutions are supporting CPUs without SSSE3. Without performance issues. Please provide a fix.
(You may use SSSE3 when it is supported by a specific CPU)
Many tools, emulators and visualization solutions are supporting CPUs without SSSE3. Without performance issues. Please provide a fix.
(You may use SSSE3 when it is supported by a specific CPU)
m....@gmail.com <m....@gmail.com> #29
If Google wants to restrict the required hardware that's up to them.
It would be good if the product supports CPU's in common use over the previous five or so years, but not necessarily those introduced further back than that. The low level of activity on this thread probably reflects the level of interest and priority the problem should be given. At least I know know where things stand.
I do think some official statement on required hardware should be provided on release. Otherwise dev's just waste their time trying to figure out what's going on. Personally this is just a hobby. I could walk away from Android development until I felt comfortable with the way forward, which for me was an easy US$100 CPU upgrade to AMD FX.
I guess if some large customer is interested in this issue they could offer to pay, or scream loudly. Google also might want to consider the goodwill and popularity of the platform amongst relatively impoverish developers tapping away at home on old desktops (who might make recommendations to less impoverished workplaces).
It would be good if the product supports CPU's in common use over the previous five or so years, but not necessarily those introduced further back than that. The low level of activity on this thread probably reflects the level of interest and priority the problem should be given. At least I know know where things stand.
I do think some official statement on required hardware should be provided on release. Otherwise dev's just waste their time trying to figure out what's going on. Personally this is just a hobby. I could walk away from Android development until I felt comfortable with the way forward, which for me was an easy US$100 CPU upgrade to AMD FX.
I guess if some large customer is interested in this issue they could offer to pay, or scream loudly. Google also might want to consider the goodwill and popularity of the platform amongst relatively impoverish developers tapping away at home on old desktops (who might make recommendations to less impoverished workplaces).
hi...@gmail.com <hi...@gmail.com> #30
#29 I think the primarily reason is that AMD CPUs are more popular among hobbyists (due to their price) rather than offices. And for hobbyists I hardly imagine this being a showstopper to Android development — they'd find this thread, see this is not fixed, and pass by to Geanymotion, which is based on VirtualBox and free for non-commercial use. So I did (well, except that I didn't pass by, but I am just an eccentric person).
> If Google wants to restrict the required hardware that's up to them.
I do agree in general, but I'm annoyed by the fact I don't see in this thread any links to a bugreport which would say that Android Emulator doesn't work on certain CPUs on Windows for the same SSSE3 reason. Just show me one, and be sure, I'd be calmed down.
> If Google wants to restrict the required hardware that's up to them.
I do agree in general, but I'm annoyed by the fact I don't see in this thread any links to a bugreport which would say that Android Emulator doesn't work on certain CPUs on Windows for the same SSSE3 reason. Just show me one, and be sure, I'd be calmed down.
bp...@gmail.com <bp...@gmail.com> #31
Any progress on this? - having the same issue on my Phenom II - this build is required for React Native emulation...
bo...@google.com <bo...@google.com>
be...@heptec.com <be...@heptec.com> #32
This just bit me in the ass today. I wonder what the reasoning behind this "feature" was?
hs...@google.com <hs...@google.com> #33
Sorry (again). I do apologize for the bad experience.
I do not understand the reasoning of forcing SSSE either. As #26 pointed out, direct way of solving the issue is not to assume SSSE. However, I do remember argument from toolchain team is "Since all x86 hardware android is currently running on has this, we can assume this to reduce maintenance effort". That does not make much sense to me. In real life, android on X86 hardware seems to be rare. And this type of reason can be used in future again and again.
Perhaps as user, you can open a bug to toolchain team asking for their help?
Back to the emulator side, we do not have any update so far. Emulating all these instructions might be a solution but we do not have time to cover this. Whether we should go this way is under discussion. SSSE is SIMD which aims performance gain in certain application. Emulating is slow as we all see in running arm image on x86.
I do not understand the reasoning of forcing SSSE either. As #26 pointed out, direct way of solving the issue is not to assume SSSE. However, I do remember argument from toolchain team is "Since all x86 hardware android is currently running on has this, we can assume this to reduce maintenance effort". That does not make much sense to me. In real life, android on X86 hardware seems to be rare. And this type of reason can be used in future again and again.
Perhaps as user, you can open a bug to toolchain team asking for their help?
Back to the emulator side, we do not have any update so far. Emulating all these instructions might be a solution but we do not have time to cover this. Whether we should go this way is under discussion. SSSE is SIMD which aims performance gain in certain application. Emulating is slow as we all see in running arm image on x86.
ra...@gmail.com <ra...@gmail.com> #34
Probably, I have the same issue with AMD Athlon 64 x2 3600+.
th...@gmail.com <th...@gmail.com> #35
3 years and still no resolution of this issue?
m....@gmail.com <m....@gmail.com> #36
I think it's pretty obvious by now that supporting old processors for desktop android development is not a priority for google. It probably doesn't help that these old CPU's are getting more ancient by the day. Best buy a new PC, or a new CPU if you have a compatible MB socket (AMD FX-6300 for US$70).
va...@gmail.com <va...@gmail.com> #37
So, per m....@gmail.com, we have to purchase a compatible MB socket (that is, AMD FX-6300)
se...@gmail.com <se...@gmail.com> #38
#37 - No, not a MB socket (MainBoard socket, i.e. the place where the CPU goes), you have to get a more recent CPU / processor that supports SSSE3. AMD introduced SSSE3 support in their FX series desktop CPUs (Bulldozer microarchitecture) in late 2011, e.g. the FX-6300, FX-8150, FX-4100, and a few more. And it's possible that your PC works with one of them without changing anything else but the processor.
The FX series CPUs use socket AM3+ which is to some extends backwards compatible to socket AM3 and that socket was used by some Phenom II era systems / mainboards. Check the (online) CPU compatibility list for your mainboard whether you have CPU upgrade options with your current board. But you can be unlucky and either have an older socket AM2+ board or a board that simply doesn't support FX series processors.
Would also check whether it's even worth upgrading an old 2008 processor to an almost equally old FX processor - it's probably the cheapest option but I would have a general look at used systems or used CPU+mainboard combinations, there are a lot out there that are more recent than the FX6300 and they are not that much more expensive.
The FX series CPUs use socket AM3+ which is to some extends backwards compatible to socket AM3 and that socket was used by some Phenom II era systems / mainboards. Check the (online) CPU compatibility list for your mainboard whether you have CPU upgrade options with your current board. But you can be unlucky and either have an older socket AM2+ board or a board that simply doesn't support FX series processors.
Would also check whether it's even worth upgrading an old 2008 processor to an almost equally old FX processor - it's probably the cheapest option but I would have a general look at used systems or used CPU+mainboard combinations, there are a lot out there that are more recent than the FX6300 and they are not that much more expensive.
th...@gmail.com <th...@gmail.com> #39
The problem is that the forcing of SSSE3 instructions was not highlighted in Android Dev. Docs before it was pushed. And like this was forced over-night on developers, who can say if the next version of emulator requires an even newer set of CPU instructions.
As such, if I buy now a FX-6300 or better AM3+ CPU and find out that with Android Studio 3.4 I need at least Ryzen or only works on Intel ... just because the people responsible with these tools don't care to deprecate it in a version or 2, with actually announcing this at least on the blog or during IO ... what do I do then ? Why are Android Tools devs copying Apple's way of "deprecating" and "improving" the tools we use ?
As such, if I buy now a FX-6300 or better AM3+ CPU and find out that with Android Studio 3.4 I need at least Ryzen or only works on Intel ... just because the people responsible with these tools don't care to deprecate it in a version or 2, with actually announcing this at least on the blog or during IO ... what do I do then ? Why are Android Tools devs copying Apple's way of "deprecating" and "improving" the tools we use ?
hs...@google.com <hs...@google.com> #40
I have to correct that it is NOT emulator or Android Studio forced an over-night change. It is Android itself who pushed that change. Things are a bit interesting here. Although system images (Android OS itself) is released together with emulator but it was not within emulator/android studio team's control. The team also has to accept such changes made by OS team. To end users, this might not be important. However, filing bugs to OS team might really solve your issue or the request could be denied as usual.
I have to agree at least we should disclose such kind of information to user.
I have to agree at least we should disclose such kind of information to user.
th...@gmail.com <th...@gmail.com> #41
Ok. I guess since it's been 3 years now I guess there are very few people willing to change things now.
How can we at this moment get a promise from the OS team that :
1. they will not change things like this (forcing users to upgrade hardware to use generic Android tools) without at least 1-2 years of prior notice
2. publish these kind of changes on Android Docs or Google Android Blog ... or anywhere that users have time to adjust
?
How can we at this moment get a promise from the OS team that :
1. they will not change things like this (forcing users to upgrade hardware to use generic Android tools) without at least 1-2 years of prior notice
2. publish these kind of changes on Android Docs or Google Android Blog ... or anywhere that users have time to adjust
?
m....@gmail.com <m....@gmail.com> #42
"As such, if I buy now a FX-6300 or better AM3+ CPU and find out that with Android Studio 3.4 I need at least Ryzen or only works on Intel ... just because the people responsible with these tools don't care to deprecate it in a version or 2, with actually announcing this at least on the blog or during IO ... what do I do then ? Why are Android Tools devs copying Apple's way of "deprecating" and "improving" the tools we use ?"
It's not like it's a major expense (compared to a new PC).
I can easily see how this could have been overlooked by google and most corporate development shops. How many of them would still be using old AMD CPU's? The problem is probably cropping up now because PC upgrades are far less worthwhile than they were 10 years ago. So many small/sole outfits have probably not bothered upgrading in years.
If these changes are truly driven by improvements to the Android OS, then I don't think the OS team should be overly constrained by having to support really old development hardware. But they should endeavour to signal changes in advance so that poorer development shops can start resourcing the support/funds for new hardware. If would also be good if they were clearer on what is/isn't going to be fixed.
It's not like it's a major expense (compared to a new PC).
I can easily see how this could have been overlooked by google and most corporate development shops. How many of them would still be using old AMD CPU's? The problem is probably cropping up now because PC upgrades are far less worthwhile than they were 10 years ago. So many small/sole outfits have probably not bothered upgrading in years.
If these changes are truly driven by improvements to the Android OS, then I don't think the OS team should be overly constrained by having to support really old development hardware. But they should endeavour to signal changes in advance so that poorer development shops can start resourcing the support/funds for new hardware. If would also be good if they were clearer on what is/isn't going to be fixed.
lf...@google.com <lf...@google.com> #43
Hi, we're wondering if anyone with this issue is seeing it on both Google APIs images and AOSP images, or only one of the two. Would anyone have time to check?
hs...@google.com <hs...@google.com> #44
#42 Thanks for understanding. I do not know the intension of such changes personally but typically with newer SIMD instructions you can get better memory load/store performance (memcpy) in addition to scientific calculations. The former is interesting since usually people won't associate it with SIMD.
hs...@google.com <hs...@google.com> #45
I will close the bug. But user can file bug to Android OS asking for removing SSSE3 requirement.
vy...@gmail.com <vy...@gmail.com> #46
Так и не исправили.
cl...@gmail.com <cl...@gmail.com> #47
Not all x86 hardware has SSSE3 CPU features, once I used a Acer x86 based tablet to run OpenSSL and found some open source library assumes SSSE3 existed in all x86 configuration and caused crash problem.
Description
I have tried :
- running without Host GPU -> same result
- increasing/decreasing RAM -> same result
- different screen sizes -> same result
- no audio -> same result
- starting a x86_64 image -> same result (these never worked for me)
- starting a ARM image -> WORKS ! (but it's far from usable)
Below is the output of the emulator start command for a Nexus 5X avd (verbose) :
emulator -avd Nexus_5X_API_23 -verbose
emulator:Found AVD name 'Nexus_5X_API_23'
emulator:Found AVD target architecture: x86
emulator:Looking for emulator-x86 to emulate 'x86' CPU
emulator:Probing program: ./emulator64-x86
emulator:Probing program: ./emulator-x86
emulator:Probing path for: emulator64-x86
emulator:return result: /data/android-sdk/tools/emulator64-x86
emulator:Found target-specific emulator binary: /data/android-sdk/tools/emulator64-x86
emulator:GPU emulation enabled using 'host' mode
emulator: Running :/data/android-sdk/tools/emulator64-x86
emulator: qemu backend: argv[00] = "/data/android-sdk/tools/emulator64-x86"
emulator: qemu backend: argv[01] = "-avd"
emulator: qemu backend: argv[02] = "Nexus_5X_API_23"
emulator: qemu backend: argv[03] = "-verbose"
emulator: Concatenated backend parameters:
/data/android-sdk/tools/emulator64-x86 -avd Nexus_5X_API_23 -verbose
emulator: found SDK root at /data/android-sdk
emulator: Android virtual device file at: /home/user/.android/avd/Nexus_5X_API_23.ini
emulator: virtual device content at /home/user/.android/avd/Nexus_5X_API_23.avd
emulator: virtual device config file: /home/user/.android/avd/Nexus_5X_API_23.avd/config.ini
emulator: using core hw config path: /home/user/.android/avd/Nexus_5X_API_23.avd/hardware-qemu.ini
emulator: Found AVD target API level: 23
emulator: Read property file at /data/android-sdk/system-images/android-23/google_apis/x86//build.prop
emulator: No boot.prop property file found.
emulator: found skin 'nexus_5x' in directory: /home/user/IDE/android-studio/plugins/android/lib/device-art-resources
emulator: autoconfig: -skin nexus_5x
emulator: autoconfig: -skindir /home/user/IDE/android-studio/plugins/android/lib/device-art-resources
emulator: keyset loaded from: /home/user/.android/default.keyset
emulator: trying to load skin file '/home/user/IDE/android-studio/plugins/android/lib/device-art-resources/nexus_5x/layout'
emulator: autoconfig: -kernel /data/android-sdk/system-images/android-23/google_apis/x86//kernel-qemu
emulator: Target arch = 'x86'
emulator: Auto-config: -qemu -cpu qemu32
emulator: Auto-detect: Kernel image requires legacy device naming scheme.
emulator: Auto-detect: Kernel does not support YAFFS2 partitions.
emulator: autoconfig: -ramdisk /data/android-sdk/system-images/android-23/google_apis/x86//ramdisk.img
emulator: Using initial system image: /data/android-sdk/system-images/android-23/google_apis/x86//system.img
emulator: autoconfig: -data /home/user/.android/avd/Nexus_5X_API_23.avd/userdata-qemu.img
emulator: autoconfig: -initdata /home/user/.android/avd/Nexus_5X_API_23.avd/userdata.img
emulator: autoconfig: -cache /home/user/.android/avd/Nexus_5X_API_23.avd/cache.img
emulator: autoconfig: -sdcard /home/user/.android/avd/Nexus_5X_API_23.avd/sdcard.img
emulator: Physical RAM size: 1536MB
emulator: GPU emulation enabled using 'host' mode
emulator: CPU Acceleration: working
emulator: CPU Acceleration status: KVM (version 12) is installed and usable.
emulator: WARNING: Host CPU is missing the following feature(s) required for x86 emulation: SSSE3
Hardware-accelerated emulation may not work properly!
Content of hardware configuration file:
hw.cpu.arch = x86
hw.cpu.model = qemu32
hw.ramSize = 1536
hw.screen = touch
hw.mainKeys = no
hw.trackBall = no
hw.keyboard = yes
hw.keyboard.lid = no
hw.keyboard.charmap = qwerty2
hw.dPad = no
hw.gsmModem = yes
hw.gps = yes
hw.battery = yes
hw.accelerometer = yes
hw.audioInput = yes
hw.audioOutput = yes
hw.sdCard = yes
hw.sdCard.path = /home/user/.android/avd/Nexus_5X_API_23.avd/sdcard.img
disk.cachePartition = yes
disk.cachePartition.path = /home/user/.android/avd/Nexus_5X_API_23.avd/cache.img
disk.cachePartition.size = 66m
hw.lcd.width = 1080
hw.lcd.height = 1920
hw.lcd.depth = 16
hw.lcd.density = 420
hw.lcd.backlight = yes
hw.gpu.enabled = yes
hw.gpu.mode = host
hw.initialOrientation = portrait
hw.camera.back = none
hw.camera.front = none
vm.heapSize = 64
hw.sensors.proximity = yes
hw.sensors.magnetic_field = yes
hw.sensors.orientation = yes
hw.sensors.temperature = yes
hw.useext4 = yes
kernel.path = /data/android-sdk/system-images/android-23/google_apis/x86//kernel-qemu
kernel.parameters = androidboot.hardware=goldfish clocksource=pit android.checkjni=1
kernel.newDeviceNaming = no
kernel.supportsYaffs2 = no
disk.ramdisk.path = /data/android-sdk/system-images/android-23/google_apis/x86//ramdisk.img
disk.systemPartition.initPath = /data/android-sdk/system-images/android-23/google_apis/x86//system.img
disk.systemPartition.size = 1280m
disk.dataPartition.path = /home/user/.android/avd/Nexus_5X_API_23.avd/userdata-qemu.img
disk.dataPartition.size = 550m
.
QEMU options list:
emulator: argv[00] = "/data/android-sdk/tools/emulator64-x86"
emulator: argv[01] = "-enable-kvm"
emulator: argv[02] = "-android-hw"
emulator: argv[03] = "/home/user/.android/avd/Nexus_5X_API_23.avd/hardware-qemu.ini"
Concatenated QEMU options:
/data/android-sdk/tools/emulator64-x86 -enable-kvm -android-hw /home/user/.android/avd/Nexus_5X_API_23.avd/hardware-qemu.ini
emulator: Starting QEMU main loop
emulator: trying to find: /data/android-sdk/tools/lib/ca-bundle.pem
emulator: registered 'boot-properties' qemud service
emulator: Using kernel serial device prefix: ttyS
emulator: Ramdisk image contains fstab.goldfish file
emulator: Found format of system partition: 'ext4'
emulator: Found format of userdata partition: 'ext4'
emulator: Found format of cache partition: 'ext4'
emulator: system partition format: ext4
emulator: Mapping 'system' partition image to /tmp/android-user/emulator-qT6Ljv
emulator: nand_add_dev: system,size=0x50000000,file=/tmp/android-user/emulator-qT6Ljv,initfile=/data/android-sdk/system-images/android-23/google_apis/x86//system.img,pagesize=512,extrasize=0
emulator: userdata partition format: ext4
emulator: nand_add_dev: userdata,size=0x22600000,file=/home/user/.android/avd/Nexus_5X_API_23.avd/userdata-qemu.img,pagesize=512,extrasize=0
emulator: cache partition format: ext4
emulator: nand_add_dev: cache,size=0x4200000,file=/home/user/.android/avd/Nexus_5X_API_23.avd/cache.img,pagesize=512,extrasize=0
emulator: registered 'boot-properties' qemud service
emulator: Adding boot property: 'dalvik.vm.heapsize' = '64m'
emulator: Adding boot property: 'qemu.sf.lcd_density' = '400'
emulator: Adding boot property: 'qemu.hw.mainkeys' = '0'
emulator: Adding boot property: 'qemu.sf.fake_camera' = 'none'
emulator: Initializing hardware OpenGLES emulation support
emulator: OpenGL Vendor=[Google (ATI Technologies Inc.)]
emulator: OpenGL Renderer=[Android Emulator OpenGL ES Translator (AMD Radeon HD 6900 Series)]
emulator: OpenGL Version=[OpenGL ES 2.0 (4.5.13399 Compatibility Profile Context 15.20.1013)]
emulator: Adding boot property: 'ro.opengles.version' = '131072'
emulator: Kernel parameters: qemu.gles=1 qemu=1 console=ttyS0 android.qemud=ttyS1 androidboot.hardware=goldfish clocksource=pit android.checkjni=1 ndns=1
emulator: trying to find: /data/android-sdk/tools/bios.bin
emulator: trying to find: /data/android-sdk/tools/lib/pc-bios/bios.bin
emulator: trying to find: /data/android-sdk/tools/vgabios-cirrus.bin
emulator: trying to find: /data/android-sdk/tools/lib/pc-bios/vgabios-cirrus.bin
emulator: autoconfig: -scale 0.41946
emulator: Forcing ro.adb.qemud to "0".
emulator: control console listening on port 5554, ADB on port 5555
emulator: sent '0012host:emulator:5555' to ADB server
emulator: android_hw_fingerprint_init: fingerprint qemud listen service initialized
emulator: Initializing metrics reporting.
emulator: metrics: Processed 1 reports.
emulator: metrics: Uploaded 1 reports successfully.
emulator: UpdateChecker: skipped version check
Nothing is displayed on the emulator sceen