Fixed
Status Update
Comments
dn...@google.com <dn...@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:
dn...@google.com <dn...@google.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.
de...@gmail.com <de...@gmail.com> #4
[Comment deleted]
de...@gmail.com <de...@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).
re...@gmail.com <re...@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.
de...@gmail.com <de...@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.
st...@gmail.com <st...@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 '
ur...@gmail.com <ur...@gmail.com> #9
Any news on this issue ? It happens on N as well
ka...@buildingbetterbonds.com <ka...@buildingbetterbonds.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.
gu...@gmail.com <gu...@gmail.com> #11
Same problem with Quad-Core AMD Opteron(tm) Processor 2354
ja...@gmail.com <ja...@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.
ja...@gmail.com <ja...@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
de...@gmail.com <de...@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)
cb...@gmail.com <cb...@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
dn...@google.com <dn...@google.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
be...@gmail.com <be...@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).
su...@gmail.com <su...@gmail.com> #18
I have same issue on ubuntu, has this issue been resolved?
em...@gmail.com <em...@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.
mi...@gmail.com <mi...@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. :)
de...@gmail.com <de...@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.
mp...@gmail.com <mp...@gmail.com> #22
Yes, please fix this thing please, really annoying....
de...@gmail.com <de...@gmail.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)
re...@gmail.com <re...@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!
qa...@gmail.com <qa...@gmail.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.
em...@gmail.com <em...@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.
ja...@gmail.com <ja...@gmail.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)
de...@gmail.com <de...@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)
da...@gmail.com <da...@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).
em...@gmail.com <em...@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.
de...@gmail.com <de...@gmail.com> #31
Any progress on this? - having the same issue on my Phenom II - this build is required for React Native emulation...
sa...@gmail.com <sa...@gmail.com> #32
This just bit me in the ass today. I wonder what the reasoning behind this "feature" was?
de...@gmail.com <de...@gmail.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.
ci...@gmail.com <ci...@gmail.com> #34
Probably, I have the same issue with AMD Athlon 64 x2 3600+.
ra...@gmail.com <ra...@gmail.com> #35
3 years and still no resolution of this issue?
ke...@gmail.com <ke...@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).
ke...@gmail.com <ke...@gmail.com> #37
So, per m....@gmail.com, we have to purchase a compatible MB socket (that is, AMD FX-6300)
pa...@google.com <pa...@google.com>
pa...@google.com <pa...@google.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.
pa...@google.com <pa...@google.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 ?
Description
I'm also having issues with all streaming music playback since updating. Google Music and Pandora have continuous issues. If I select a recent playlist or station on google music it will not play. It attempts to play a song for a few seconds then jumps to the next and fails again. Eventually it says 'unable to play song' or something of that nature. I'm unable to get Pandora to even play music.
Oddly if I ask Google Music to play a station using voice it works. However once playing it seems to stop the song in places where I have even a very short lapse in coverage. If I hit play again it starts the same song over from the beginning. Not sure if this is a buffering issue?
Running Android P, latest build on my Pixel XL
Android auto issues are happening in my 2016 VW GTI
Prior to updating I had zero issues with Android Auto in the GTI
This form is for issues and requests related to the Android P Developer Preview only. Please only report issues that are regressions from the behavior in Android P. For all other issues that also reproduce on other versions of Android, please file it in the AOSP issue tracker at
If the issue is not due to a platform bug, we will do our best to notify the developer. However, note that it is the up to the the developer to actually address reported issues.
Before logging your issue, check to see whether it is a known issue described in the current release notes at:
or has already been reported at:
If the issue has already been reported, you can "star" or comment on the existing report if it corresponds to the issue you are seeing.
To expedite resolution of your issue, please provide as much relevant and specific information as possible. This will probably require some work from you. Most reports should include at least the following:
* Which Developer Preview build are you using? See Settings > About phone > Build number (for example OPP5.170921.005).
* Is this a regression from O to P?
* What device are you using? (for example, Pixel XL)
* What are the steps to reproduce the problem? (Please provide the minimal reproducible test case.)
* Issue Category e.g. Framework (platform), NDK (platform), Hardware (CPU, GPU, Sensor, Camera), ART (platform), Runtime Permissions etc
* What was the expected result?
* Can you provide the API document where this expected behavior is explained?
* What was the actual result?
* Relevant logcat output.
* Link to captured Android bug report (shared privately in Drive.)
* Optional: Link to any screenshot(s) that demonstrate the issue (shared privately in Drive.)
To avoid leaking private information, please share screenshots and bugreports only in Google Drive. Share files with android-bugreport@google.com and include only Google drive links in your bug. Bug report attachments should not be included directly in issue reports.