WAI
Status Update
Comments
vs...@google.com <vs...@google.com> #2
Here's a really detailed StackOverflow answer that seems to point out some things to look at in relation to this behaviour:
http://stackoverflow.com/a/14293528/238753
bh...@gmail.com <bh...@gmail.com> #3
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
hw...@gmail.com <hw...@gmail.com> #4
Tested and confirmed that this bug affects Android 4.4 - 5.1 but was fixed in Android 6.0.
I've attached an updated sample project since the original one needed some tweaks to get it building.
I've attached an updated sample project since the original one needed some tweaks to get it building.
hw...@gmail.com <hw...@gmail.com> #5
Oh I forgot, I also ran "dpkg --add-architecture amd64" and "apt-get install libc6:amd64" to install the base 64-bit libraries. The 64-bit SDK binaries only use the base libs, if some 64-bit software needed more you'd have to install other lib(whatever):amd64 as needed.
pi...@gmail.com <pi...@gmail.com> #6
I also ran into this issue today.
I have restored the platform-tools to 23.0.1 and it's working fine now.
But,Project Member mentioned that some parts will be 64 bits only. This would make 32 bit linux user's life difficult.
I might not be able to use emulators either, because of limited resources and CPU power.
Hence I request you not to remove 32 bit support.
I have restored the platform-tools to 23.0.1 and it's working fine now.
But,Project Member mentioned that some parts will be 64 bits only. This would make 32 bit linux user's life difficult.
I might not be able to use emulators either, because of limited resources and CPU power.
Hence I request you not to remove 32 bit support.
re...@gmail.com <re...@gmail.com> #7
I've had this problem as well on my 32-bit Linux system. I fixed it using the zip file mentioned above which allowed me to go back to platform-tools 23.0.1.
It's worth noting that the SDK Manager in Android Studio is not working properly on 32-bit Linux. It should detect a 32-bit system and block the user from installing platform-tools 23.1.0 (which makes ADB unusable).
Tools>Android>SDK Manager>SDK Tools
It's worth noting that the SDK Manager in Android Studio is not working properly on 32-bit Linux. It should detect a 32-bit system and block the user from installing platform-tools 23.1.0 (which makes ADB unusable).
Tools>Android>SDK Manager>SDK Tools
bu...@gmail.com <bu...@gmail.com> #8
I'd like to whine here as well as I'm still using 32bit Ubuntu on several low-end machines.
The release note is no where to be found on [SDK Tools Release Notes | Android Developers](http://developer.android.com/intl/zh-tw/tools/sdk/tools-notes.html ), and that the most ridiculous part is that the latest SDK release note states:"Fixed a regression on the 32-bit Windows OS where the emulator fails to boot Android 6.0 (API level 23) through Android 5.0 (API level 21) system images."
Please don't assume every developer uses AMD64 systems, thank you.
The release note is no where to be found on [SDK Tools Release Notes | Android Developers](
Please don't assume every developer uses AMD64 systems, thank you.
de...@gmail.com <de...@gmail.com> #9
Please document this in the release notes or Linux system requirements on the SDK page. It took me over an hour to find this change.
fr...@gmail.com <fr...@gmail.com> #10
I also downgrade to 23.0.1
All people with linux in a 32 bits machine can not develop for android in next future...?????
Should we all buy new 64 bits machines? :/
Do not remove 32 bit support!
All people with linux in a 32 bits machine can not develop for android in next future...?????
Should we all buy new 64 bits machines? :/
Do not remove 32 bit support!
wi...@gmail.com <wi...@gmail.com> #11
It is unfortunate this kind of unnoticed change, indeed. I tend to develop for Android inside VMs, and when I choose Linux I go 32-bit because of so many stability issues I've been through some years ago with 64-bit ones.
Maybe it's time to start trusting the 64-bit editions, I guess I've been lazy to not check all the changes and distros scenarios, but either way I spent some hours myself too until I reached some stack overflow topic, then here, to find out about this.
When you come from 1.5-2.0 Android development scenario and watch what they present nowadays - i.e. last Android Dev presentations - you think it's finally a mature platform but after this one, again I guess I was mistaken. No doubt it has became an absurdly evolved platform, seeing from what it came from, but we still get those out-of-nowhere critical issues, labeled as 'stable', it's hard to trust the 'update button'.
Anyways, pros and cons, and sure thing - to me - the pros are way ahead. But this kind of issue can break an entire development environment - in my case, at least, means to redo all the VMs in the near future. I hoped we would have been warned about this earlier.
Maybe it's time to start trusting the 64-bit editions, I guess I've been lazy to not check all the changes and distros scenarios, but either way I spent some hours myself too until I reached some stack overflow topic, then here, to find out about this.
When you come from 1.5-2.0 Android development scenario and watch what they present nowadays - i.e. last Android Dev presentations - you think it's finally a mature platform but after this one, again I guess I was mistaken. No doubt it has became an absurdly evolved platform, seeing from what it came from, but we still get those out-of-nowhere critical issues, labeled as 'stable', it's hard to trust the 'update button'.
Anyways, pros and cons, and sure thing - to me - the pros are way ahead. But this kind of issue can break an entire development environment - in my case, at least, means to redo all the VMs in the near future. I hoped we would have been warned about this earlier.
op...@gmail.com <op...@gmail.com> #12
Hello,
Same here :
"Do not remove 32 bit support!"
Thanks,
Eric
Same here :
"Do not remove 32 bit support!"
Thanks,
Eric
br...@gmail.com <br...@gmail.com> #13
Hello ,
Same here:
" Please do not remove 32 bit support! We NEED it! "
Thanks,
Victor
Same here:
" Please do not remove 32 bit support! We NEED it! "
Thanks,
Victor
wm...@gmail.com <wm...@gmail.com> #14
Hello ,
Same here:
" Please do not remove 32 bit support! We NEED it! "
Thanks,
Wesley
Same here:
" Please do not remove 32 bit support! We NEED it! "
Thanks,
Wesley
ma...@gmail.com <ma...@gmail.com> #15
Hello ,
Same here:
" Please do not remove 32 bit support! We NEED it! "
Thanks,
Marian
Same here:
" Please do not remove 32 bit support! We NEED it! "
Thanks,
Marian
[Deleted User] <[Deleted User]> #16
@hwert Thank you very much for your detailed help! I installed qemu (2.5+dfsg-4+b1) from debian testing (precompiled there). That and libc6:amd64 take about 250mb additional space, and no complaints about performance.
The only issue I run into is that 32-bit 23.0.1 'adb devices' finds my device and works, while 64-bit 23.1.0 'adb devices' using qemu lists *no* devices (and yes I killed/started the adb server on each test, with many tests). I'm guessing I need libusb-1.0-0:amd64 or something?
The only issue I run into is that 32-bit 23.0.1 'adb devices' finds my device and works, while 64-bit 23.1.0 'adb devices' using qemu lists *no* devices (and yes I killed/started the adb server on each test, with many tests). I'm guessing I need libusb-1.0-0:amd64 or something?
[Deleted User] <[Deleted User]> #17
@hwert libusb-1.0-0:amd64 didn't help. I think on my system updating libc6 to testing from stable messed things up. Compiling from source as you did would be best.
That's a lot of work so I went back to using older 32 bit platform-tools for now.
That's a lot of work so I went back to using older 32 bit platform-tools for now.
ch...@google.com <ch...@google.com> #18
so...@gmail.com <so...@gmail.com> #19
solution no 3 worked for me.i am running linux mint 32 bit .
guys...please dont remove support for 32 bit systems for atleast another 1 year please.
there are people who cant afford new systems and trying to get a breakthrough with existing 32 bit systems..please dont forget us..
guys...please dont remove support for 32 bit systems for atleast another 1 year please.
there are people who cant afford new systems and trying to get a breakthrough with existing 32 bit systems..please dont forget us..
hw...@gmail.com <hw...@gmail.com> #20
"The only issue I run into is that 32-bit 23.0.1 'adb devices' finds my device and works, while 64-bit 23.1.0 'adb devices' using qemu lists *no* devices (and yes I killed/started the adb server on each test, with many tests). I'm guessing I need libusb-1.0-0:amd64 or something?"
The short of it, adb actually *didn't* work for me, it (as you found) no longer crashed but didn't actually contact the phone. I replaced the adb in the Anrdoid SDK with a different copy that does run. Sorry!
I'm actually now using a quad-core ARM to develop on. This actually only took three steps:
1) Build and set up qemu as described above. (Since I did this to get adb support, and adb still didn't work, you can probably use whatever qemu version, add binfmt support for x86_64 manually if you're on x86.)
2) android-sdk-linux/tools/lib has "x86" and "x86_64" subdirectories with "swt.jar" in each. go in .../tools/lib/, make an "arm" directory, and put /usr/share/java/swt.jar in there (this swt should match your native system's libraries, not the x86/x86_64 used by the SDK). I don't use "monitor" but I think it would need similar treatment (it would try to look at "libs/monitor-x86" or "libs/monitor-x86_64", you should copy one or the other into "libs/monitor-arm" so it has the .jar fies and such, but replace "libcairo-swt.so" with equivalent file from "/usr/lib/jni/".) I didn't try to use the emulator, after I gave it 10 minutes to boot... well, it took at least that long on my previous x86 system too. I'm going for debug-on-phone.
3) I installed Ubuntu package "android-tools-adb", then copied /usr/bin/adb into android-sdk-linux/platform-tools/ . The rest of the SDK system does not seem to actually mind adb being rather out of date. You might need to run adb-killserver if you have an old one still hanging around.
Note this is quite viable, I've found on a ~4 minute build (which took over 10 minutes on my previous Core Duo system...) that the slowest qemu-emulated part (aapt) took about 2 seconds.
The short of it, adb actually *didn't* work for me, it (as you found) no longer crashed but didn't actually contact the phone. I replaced the adb in the Anrdoid SDK with a different copy that does run. Sorry!
I'm actually now using a quad-core ARM to develop on. This actually only took three steps:
1) Build and set up qemu as described above. (Since I did this to get adb support, and adb still didn't work, you can probably use whatever qemu version, add binfmt support for x86_64 manually if you're on x86.)
2) android-sdk-linux/tools/lib has "x86" and "x86_64" subdirectories with "swt.jar" in each. go in .../tools/lib/, make an "arm" directory, and put /usr/share/java/swt.jar in there (this swt should match your native system's libraries, not the x86/x86_64 used by the SDK). I don't use "monitor" but I think it would need similar treatment (it would try to look at "libs/monitor-x86" or "libs/monitor-x86_64", you should copy one or the other into "libs/monitor-arm" so it has the .jar fies and such, but replace "libcairo-swt.so" with equivalent file from "/usr/lib/jni/".) I didn't try to use the emulator, after I gave it 10 minutes to boot... well, it took at least that long on my previous x86 system too. I'm going for debug-on-phone.
3) I installed Ubuntu package "android-tools-adb", then copied /usr/bin/adb into android-sdk-linux/platform-tools/ . The rest of the SDK system does not seem to actually mind adb being rather out of date. You might need to run adb-killserver if you have an old one still hanging around.
Note this is quite viable, I've found on a ~4 minute build (which took over 10 minutes on my previous Core Duo system...) that the slowest qemu-emulated part (aapt) took about 2 seconds.
jc...@gmail.com <jc...@gmail.com> #21
This workaround works for me! Txs
vh...@google.com <vh...@google.com> #22
Just a heads up that the new emulator and future versions of the NDK will also require 64 bit Linux. If you are running 32 bit Linux, your best bet is to stop updating any Android developer tools. I'm sorry for the inconvenience but we need to focus our limited resources on fewer targets.
la...@gmail.com <la...@gmail.com> #23
I 3 years I came back to developoment in android and same now they are not supporting to tun emulator ... now I have to take the deb and run on my mobile to check the app...
without adb working properly I can not even do usb debugging what a Shame!!! Bup!!!!
without adb working properly I can not even do usb debugging what a Shame!!! Bup!!!!
vh...@google.com <vh...@google.com>
ku...@gmail.com <ku...@gmail.com> #24
where is Android emulator binary for 32-bit linux ?
vh...@google.com <vh...@google.com>
ak...@gmail.com <ak...@gmail.com> #25
Unable to create Debug Bridge: Unable to start adb server: Unable to detect adb version, adb output: /root/Android/Sdk/platform-tools/adb: 1: /root/Android/Sdk/platform-tools/adb: Syntax error: ")" unexpected
qu...@gmail.com <qu...@gmail.com> #26
Google love removing features from their products and projects for no reason. Hope to see many angry reviews soon. Be warned guys!!
ra...@gmail.com <ra...@gmail.com> #27
Few days back I thought I should learn Android development. I went to android studio page and download button read "download android studio 2.3.3 for linux (468 mb)". I clicked on it and the download started after accepting license agreement. I installed it, it installed smoothing. However, when I ran it it started showing error. I checked through the internet to find a solution. Whole internet is full of the problem same as mine. After seeking solution for couple of days I ended up on this thread to find that android studio will not run on 32 bit system. Seriously? Are you kidding me? What kind of intended behavior was that, not to even notify the users!
If you don't want to support 32 bit Linux system and "you need to focus your limited resources on fewer targets", then, at the very least, mention in your download page the architecture of android which people are downloading. What great resources it takes to mention 64-bit on the download button? And what great resources it takes to mention that current version of android studio doesn't support 32-bit Linux? What great resources it takes to provide a link on the download page for the last version of android studio which supported 32-bit Linux; as some people like me would like to learn android development, can't afford to by a new 64-bit computer right now and hate using windows or mac? Does google believe that android development can be done only by the elites? After using the Linux kernel to build android and making billions of dollars, not to provide the support to the world-wide Linux users is being ungrateful and amounts to treason!
If you don't want to support 32 bit Linux system and "you need to focus your limited resources on fewer targets", then, at the very least, mention in your download page the architecture of android which people are downloading. What great resources it takes to mention 64-bit on the download button? And what great resources it takes to mention that current version of android studio doesn't support 32-bit Linux? What great resources it takes to provide a link on the download page for the last version of android studio which supported 32-bit Linux; as some people like me would like to learn android development, can't afford to by a new 64-bit computer right now and hate using windows or mac? Does google believe that android development can be done only by the elites? After using the Linux kernel to build android and making billions of dollars, not to provide the support to the world-wide Linux users is being ungrateful and amounts to treason!
mc...@gmail.com <mc...@gmail.com> #28
Same here: google becomes to be a crap! -> do not remove 32 bit support! We NEED it!
noted that stupid windo users still have 32bits support
noted that stupid windo users still have 32bits support
Description
I'm running Ubuntu 14.04.1 32-bit (it's a Core Duo T2300, so no 64-bit support...) with android-sdk_r24.4.1, with both eclipse + ADT and android-studio (141.2456560) installed. I set ANDROID_EMULATOR_FORCE_32BIT=true .
I did actually install qemu-user-static (and libc6:amd64), and add a binfmt entry for qemu-user-x86_64. With this setup, "adb" runs OK. But "adb start-server" exits with signal 11, probably due to a system call not handled by qemu.
I suggest one of the following:
1) If building platform-tools as 64-bit was an oversight, please ship 23.1.1 or 23.2 or whatever as 32-bit.
2) If it's not an oversight, please place something in the update notes letting Linux users know Platform-Tools 23.0.1 is the last 32-bit Linux build.
3) I'd be interested to find out if qemu-user-x86_64 is just missing something trivial that keeps it from running adb. Java burns through all sorts of CPU time running either eclipse+ADT or Android-Studio. But other than emulator (to run an emulated Nexus 5 in my case), the other native executables use so little CPU time that they could probably all run under qemu-user_x86_64 without a noticeable difference. This'd be interesting to pursue too, because I plan to go get a ARM Chromebook and make it dual-boot Ubuntu; I'd prefer to be able to do some Android development on there too, which should be fully doable as long as the native bins run under qemu.