[android-developers] Re: Nexus 7 not visible to adb over usb (WIndows 7 x64, up to date Jelly Bean sdk)
I'm happy to answer my own question. 1) Can't blame Windows! 2) When the Nexus 7 is plugged in there is a persistent notification that indicates CONNECT AS / Media Device (MTP). In this state adb devices will not show the Nexus. Not exactly obvious why, but I you select the second option Camera (PTP) the device is available for debugging. This choice is persistent, and I'm guessing that with a band new device it will connect as MTP until told otherwise. On Friday, August 10, 2012 8:39:08 AM UTC-7, mkh wrote: Trying to force feed myself Windows to build character, and the seemly trivial thing of plugging in a Nexus 7 to a Dell xps 15z Tand debugging a hello world app on it from Eclipse Juno with the latest ADT plugin has me stumped. Developer options were turned on, and USB debugging enabled. The device just does not show up, not in Eclipse, or in adb devices. The first time I had not installed the USB driver from the sdk. In this case the Nexus 7 shows up in the WIndows devices under Portable Devices and a filesystem can be browsed from Windows. Next I installed the google USB driver. Now the Nexus 7 shows up in the Windows devices as Android Phone/Android composite ADB interface, and at that point I thought I was moments away from looking at Hello World and moving on to something interesting, but wait, there's more, adb remained blind to the Nexus7. Any ideas, or suggestions for debugging this problem would be appreciated... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Nexus 7 not visible to adb over usb (WIndows 7 x64, up to date Jelly Bean sdk)
The driver there appears to be the same as the one in the android SDK. I installed it anyway, and the result is the same -- PS C:\Users\mkh\AppData\Local\Android\android-sdk\platform-tools $env:ADB_TRACE='all' PS C:\Users\mkh\AppData\Local\Android\android-sdk\platform-tools $env:ADB_TRACE all PS C:\Users\mkh\AppData\Local\Android\android-sdk\platform-tools ./adb devices system/core/adb/adb.c::main():Handling commandline() system/core/adb/adb_client.c::adb_query():adb_query: host:devices system/core/adb/adb_client.c::_adb_connect():_adb_connect: host:version system/core/adb/sysdeps_win32.c::socket_loopback_client():socket_loopback_client: port 5037 type tcp = fd 100 system/core/adb/transport.c::writex():writex: fd=100 len=4: 30303063 000c system/core/adb/transport.c::writex():writex: fd=100 len=12: 686f73743a76657273696f6e host:version system/core/adb/transport.c::readx():readx: fd=100 wanted=4 system/core/adb/transport.c::readx():readx: fd=100 wanted=4 got=4 4f4b4159 OKAY system/core/adb/adb_client.c::_adb_connect():_adb_connect: return fd 100 system/core/adb/adb_client.c::adb_connect():adb_connect: service host:devices system/core/adb/transport.c::readx():readx: fd=100 wanted=4 system/core/adb/transport.c::readx():readx: fd=100 wanted=4 got=4 30303034 0004 system/core/adb/transport.c::readx():readx: fd=100 wanted=4 system/core/adb/transport.c::readx():readx: fd=100 wanted=4 got=4 30303164 001d system/core/adb/sysdeps_win32.c::adb_close():adb_close: 100(lo-client:5037) system/core/adb/adb_client.c::_adb_connect():_adb_connect: host:devices system/core/adb/sysdeps_win32.c::socket_loopback_client():socket_loopback_client: port 5037 type tcp = fd 101 system/core/adb/transport.c::writex():writex: fd=101 len=4: 30303063 000c system/core/adb/transport.c::writex():writex: fd=101 len=12: 686f73743a64657669636573 host:devices system/core/adb/transport.c::readx():readx: fd=101 wanted=4 system/core/adb/transport.c::readx():readx: fd=101 wanted=4 got=4 4f4b4159 OKAY system/core/adb/adb_client.c::_adb_connect():_adb_connect: return fd 101 system/core/adb/adb_client.c::adb_connect():adb_connect: return fd 101 system/core/adb/transport.c::readx():readx: fd=101 wanted=4 system/core/adb/transport.c::readx():readx: fd=101 wanted=4 got=4 30303030 system/core/adb/transport.c::readx():readx: fd=101 wanted=0 system/core/adb/transport.c::readx():readx: fd=101 wanted=0 got=0 system/core/adb/sysdeps_win32.c::adb_close():adb_close: 101(lo-client:5037) List of devices attached PS C:\Users\mkh\AppData\Local\Android\android-sdk\platform-tools On Friday, August 10, 2012 10:18:41 AM UTC-7, goodG wrote: http://support.asus.com/download/ModelList.aspx?SLanguage=enkeyword=nexus%207type=1 my personal advice is just to avoid programming on Windows, it's a nightmare. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Nexus 7 not visible to adb over usb (WIndows 7 x64, up to date Jelly Bean sdk)
Trying to force feed myself Windows to build character, and the seemly trivial thing of plugging in a Nexus 7 to a Dell xps 15z Tand debugging a hello world app on it from Eclipse Juno with the latest ADT plugin has me stumped. Developer options were turned on, and USB debugging enabled. The device just does not show up, not in Eclipse, or in adb devices. The first time I had not installed the USB driver from the sdk. In this case the Nexus 7 shows up in the WIndows devices under Portable Devices and a filesystem can be browsed from Windows. Next I installed the google USB driver. Now the Nexus 7 shows up in the Windows devices as Android Phone/Android composite ADB interface, and at that point I thought I was moments away from looking at Hello World and moving on to something interesting, but wait, there's more, adb remained blind to the Nexus7. Any ideas, or suggestions for debugging this problem would be appreciated... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Logging should not be Android specific?? Why not SLF4J??
I am trying to understand why the logging API in Android was not made independent of the platform. SLF4J has a clean separation between the logging API, and a pluggable logging implementation. In this scheme, the Android platform would just provide the logging implementation specific for the platform, but all of the logging statements sprinkled throughout the code would just be generic SLF4J and thus not platform specific. Given that logging tends to pervade the entire codebase, it seems this separation is critical for allowing Java libraries to function in applets, web applications, and mobile applications. It is unfortunate that Sun did a poor job with the official JDK logging scheme, which lead to it not being universally adopted, but now it seems that Android has made the Java logging nightmare that much more unpleasant. Logging should really be part of the language specification rather than a library addon. There is already SLF4J for android with the logging implementation just delegating to the android logger, and so my question is, why is there not a best practice directive to use SLF4J logging, or better still, official adoption? It seems so obvious, I fear I must be ignorant of good arguments against this... Thanks for any insight! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] ENHANCEMENT: Allow java public static finals to be referenced from XML
One example from an AndroidManifest.xml: provider android:name=NotePadProvider android:authorities=com.exampl.notepad.provider.NotePad / This deliberately includes a typo that cannot be flagged by an IDE because it is just a string. Instead as an enhancement, why not define @java/ to be a reference to the a public static final, then the above becomes: provider android:name=NotePadProvider android:authorities=@java/ com.example.android.notepad.AUTHORITY / Now an IDE can provide completion on these @java variables, and the IDE can also immediately flag undefined references. Also, the definition of the authority string can be changed in one place, and the code does not break. Is there any reason this would not work -- it seems like the benefits offered are significant. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Why is android.jar not split to facilitate testing and library reuse across Android and plain old Java?
Would it not be reasonable to split the single big android.jar into multiple jar files where all of the classes that could be used in a standard Java application running with a vanilla J2SE appear in a subset of the jar files, along the lines of an API jar and and a couple of implementation jar's. This would facilitate testing, and also allow development of libraries that could be used for example in a standard Java web application and in an Android mobile application. As a specific example, a library that encapsulates the interaction with some web service may define Java entity classes, and for Android RPC these may need to implement android.os.Parcelable. This drags in andorid.os.Parcel which seems to be intimately connected to the Android platform, and yet this is just a serialization scheme equally applicable to a web application... Would appreciate any discussion to clarify my thinking (seasoned in Java, but still a bit green in the Android world)... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
