I've turned on USB debugging. I have the latest HTC Sync and android SDK components. I'm using Eclipse 3.5 on windows XP. I'm running Android 2.2, and am asking for 2.1 as the minimum in the debugger. I work in Eclipse/Java just about every day, and have for several years. I'm even writing an Eclipse plugin at work as I type this.... neither Eclipse nor Java are new to me by quite a stretch.
When I start a debug session for the "Skeleton App" sample project, I can see my Evo, and the activity launches (with any freshly saved changes), should I select it.
BUT: my breakpoints are ignored, and logCat doesn't see my app's output(see comments below).
*W*hat a *T*errible *F*ailure (As the api so artfully puts it)!
(oh look... a formatting bug. Looks like bold text wants white space to function properly 10/15/2010)
I have tried different android connection types (charge only, disk drive, HTC Sync, and USB tethering) to no avail. I've tried Eclipse 3.6 for a bit before yielding to the inevitable and reinstalling 3.5. I monkeyed with the emulator for a while but ran into a different set of issues (I had to reboot the emulator every time I wanted to make a change... Eclipse's auto-build/hot-swap has me spoiled).
Is there something I can add to (or remove from) the AndroidManifest.XML to deal with this? A magical incantation perhaps? Must I pray towards San Jose three times a day on a rug woven from kernel gurus' vast and scruffy beards? Is my Evo not Kosher? Must I be "sky clad" while debugging? Shall I teach my laptop to genuflect?
Have you followed all the points from here ? You need to set a flag in the manifest and also enable debugging on the actual device.
I found the solution to the debugger issue. Google comes through again:
I found an IOException hiding in my DDMS log: Address family not supported by protocol family: bind
Googling for that, plus "android" turned up the answer in the first link. Windows Vista specifies "localhost" as ":::1", but android doesn't really support IPv6 yet. Changing localhost to "127.0.0.1" resolved the issue.
This is defined in c:/windows/system32/drivers/etc/hosts. I needed to run notepad "as admin" in order to save the changes.
I also have an HTC Evo 4G, and have been having the same debugging problems with Eclipse Helios (3.6). I just learned to use this debugger a day or two ago, and it worked fine. I noticed that there was an automatic Android OS update in the last day or two, also. Perhaps this is just a coincidence.
BUT - my beard was indeed scruffy yesterday, as you suggest, and the debugger was working. I've since shaved. Bad idea, apparently.
Butt seriously - I powered down both Evo and computer (HP running Vista), removed battery from both, then started over. Same result, that is, no debugging.
Related
We are debugging an issue with one of our apps which affects only Huawei devices. To debug it, we purchased P20 Lite ANE-LX1. We've placed some breakpoints in our code and are investigating the full stack trace. The device has Android 8.0 installed, and we have the same SDK downloaded in our Android Studio.
When we attach our device to a debugger and try to investigate the stack trace we get the following errors in system source files:
After playing with the stack trace, we can confirm that indeed our source files do not correspond to what is installed on the device. Sometimes, the debugger points to a line where functionA is called, and in the stack trace, we see that functionB is called instead. The files which we could confirm are affected by this issue are:
VideoView,
MediaPlayer,
ContentProvider.
We've tried all the possible solutions which we could find, including cleaning the project, deleting any additional SDKs from Android Studio, modifying project settings - nothing helps to resolve this issue.
This leads us to believe that Huawei installs a modified version of Android 8.0 on their devices which is why we cannot debug the stack trace for the system files. We did contact Huawei to try and clarify this.
In the meantime, we'd appreciate if you could throw any relevant ideas at us. Maybe you know where to get the source files which Huawei installs on their devices? Or maybe you know how to fix this mismatch between source code and bytecode in some other way?
Update 1
Following the advice of Robert, I uninstalled the source codes for Android 26 and ran the app again on my Huawei. As soon as I jumped into the VideoView file, I saw the following picture:
I clicked on "Download" and it started downloading the source files:
After this, I was able to step into VideoView and it seemed to work fine. However, after this line it became obvious that these source files are also wrong:
When I try to step into the requestLayout function I get this:
And it is obviously a wrong result. In fact, if I click on "Step to the next line" I see the message about source code mismatch with the bytecode again.
Apparently Huawei forked AOSP and modified it's sources. This is what many manufacturers do and it's perfectly fine as long as source passes the Compatibility Test Suite. I myself saw encrypted video playback issues on Huawei P20 related to their approach to customizing the ROM.
But getting back to the point - you can get the exact framework code running on your device from /system/framework/arm/boot.oat or boot-framework.oat or /system/framework/boot.vdex. I don't know exactly how these files are structured but it varies between Android versions and between manufacturers. Once you get these files by adb pull (You surely need root to do this) you can perform oat->dex, dex->jar using dex2jar or other tools and you'll get the source. Traditionally it was possible to get framework code from /system/framework/framework.jar but after ART was introduced these files are often empty on system images and precompiled framework code is used instead.
I believe I ran into a similar issue on my phone, but I am using a Google Pixel. I was initially concerned that the phone was compromised somehow. I think it is less likely an issue with Huawei and more likely an issue with Android Studio not keeping the source packages up to date. Your Component Installer screenshot shows Android Studio downloading revision 1 of the SDK Source - yet most SDKs are using a later revision.
I detailed the solution to my problem elsewhere on StackOverflow: Source code does not match the bytecode for Android's View.java
I've been encountering this issue that I find has no information on the web and would like some help as I've been working on this for the last few days with no leads.
Why does my java app suddenly stop working for APFS? It works if I move the app to a non-APFS USB, but when I move the App to the SSD which is formatted to APFS, it stops working.
When I checked the app logs, it turns out that for some reason, certain libraries are not being properly imported/recognized by the app when it is run from the SSD formatted to APFS. Why would it behave differently in an APFS SSD vs an HFS+ usb/hard drive?
I've already isolated the case and found that only the APFS is the common factor. I've tested it in other devices, those that run High Sierra without an APFS drive, and those that run Sierra with an SSD that has not yet been converted to an APFS drive, and only those devices which utilize APFS filesystem formatting are encountering the issue.
Additional Information:
Java App has been properly signed, it is distributed personally but not via the App Store.
App is bundled using AppBundler not JavaPackager.
App runs on previous versions of OSX, and has been distributed and tested working on hundreds of Mac Devices with OSX varying between 10.8 - 10.12
Libraries that somehow don’t get recognize are the apache libraries, like commons-lang-2.6 (We haven’t upgraded to 3 yet), commons-logging (had to output the logs manually onto desktop to see what was happening). Strangely, app was able to import sqlite library properly.
Thanks for looking, and would appreciate any advice!
I’ve managed to fix the above issue, but I’m unsure as to why.
Solution:
Update commons.lang.2.6 to commons.lang.3.6
Currently, I’m hoping that it will not encounter any other issue aside from that, but I can only guess as to what was happening.
I think APFS cached a copy of commons.lang.3.6 and used that library instead of my own, so there was an issue with class loaders trying to find the 2.6 version. Since only APFS would have a cached copy, it would allow my app to run on a USB.
I don’t actually know the correct etiquette for finding out the answer to your own question, so please feel free to correct my post if there’s anything I need to change.
So I downloaded the ADT bundle at the android website. I tried making a simple project, the one with HelloWord program. I already added an AVD and tried to run my application. At first, I got stuck at
"Waiting for HOME ('android :process:acore') to be launched"
but after searching the net, I learned that I must right click my project and click run as Android Application and then it was able to proceed with the next lnes in the console.
But after some lines, it gets stuck at the line in the console saying
"Starting activity.com.example.myfirstapp.MainActivity on device emulator:5554"
it's been an hour since that line and nothing has happened in the AVD. I tried using 2 ADT bundles, one for my 32-bit computer and one for my 64-bit computer. Both get stuck at the same line. How do I solve this? I've been working with this issue the whole day. Just when I thought it would be a simple installation.
Launch your emulator from Android Virtual Device(AVD) Manager and run your application
One thing that can really stick your program is a virtual device that is eating up too many resources. Try lowering the amount of RAM your virtual device has. Also be sure you have the latest JDK/JRE installed.
Just picked this book up:
http://www.amazon.com/Android-Development-From-Eclipse-ebook/dp/B00EEI5NHO/
Decently well written an very easy to follow. Walks through building an app in decent detail.
Actually the AVD works very slow on normal configuration systems, it requires a very high config PC to run smooth, you have to wait for sometime to continue with AVD, it will start don't worry. But I would recommend you to run and test your apps on a real android device using the USB debugging feature.
I'm trying to use Bluecove for an application I'm writing. Version 2.1 of the jar didn't work, so a little Google showed me that it had always had issues with x64, so I turned to the latest 2.1.1 "snapshot", and I still get that the bluecove_x64 dll is missing. Am I doing something wrong, or should I just look for another API?
I encountered this problem after installing a vendor's bluetooth stack and management utilities. My java app which used bluetooth worked fine before this, after the install I got the bluecove_x64.dll not found error. After much searching, I reverted to an earlier system checkpoint (before I tried installing the "newer" bluetooth) and all was back to normal.
On another system, the toshiba bluetooth software had already been installed. I did a system checkpoint (in case the following was to not work), then went into the device manager, and uninstalled every "device" under bluetooth. Be sure to check the "delete driver software" box too, or they will come right back.
After this, the bluetooth device will appear to be gone. Go to the top of the tree, right click, and do "scan for hardware changes". This should install the Microsoft generic bluetooth drives which then work (for me) just fine on Win7_x64. If this doesn't install them, then you may try searching for a download, or another stack.
I am a noob to Android (and Java). I have successfully setup Eclipse and the Android Virtual Device (AVD). I am guessing the AVD's Target is the version of Android to be emulated, but I want to make sure. I am trying to develop something for my Droid X2 phone.
As such...
Which AVD Target is the right one for a Droid X2?
Is there an online list someplace explaining each Target?
...I have Googled both unsuccessfully.
Thank you for the help.
According to motorolas website, the Droid X2 ships with Android 2.2 (api level 8).
I'm not sure if there are any updates rolled out yet, so consider this the lowest version you will get for this device.
So target 2.2. or lower.
But just a general advice: If you want to ship your app to other people, it's usually best to target the broadest audience. So I recommend going for 1.6 as a target, that will still run on your phone. You can start to raise the target version when you notice that you need a certain feature (can be easily done from the "project properties" dialog inside eclipse in 5 seconds). If you don't seem to need any higher api features, you are way more compatible to many more devices this way.
Edit: To the targets. See Android API levels. Clicking on a version takes you to the changelog. Theres info whats new. Also notice that anything below and equal 2.3.3 is a phone os at the moment. Anything equal or above 3.0 is a tablet os.