[android-developers] Re: Bluetooth Low Energy (4.0) on android 4.4 device.
Use an older example that does not rely on Android 6:
http://toastdroid.com/2014/09/22/android-bluetooth-low-energy-tutorial/
On Friday, October 14, 2016 at 2:21:10 PM UTC-6, Александр Сергеевич Джус
wrote:
>
> Hello, I want to use Bluetooth 4.0 to connect the Vert device. The problem
> is,that I have android 4.4, but your official example is based on android
> 6.0. I rebuilded this example to work on my device, it starts with
> problems (I can connect and get BleService(s)/BleCharacteristic(s), but
> haracteristic.getValue("...") always null ). So can you say what is wrong,
> and what should I do to get Vert's values ?
>
--
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/android-developers/f1f3044d-39d6-4838-9305-1adbd78d092a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Android Virtual Device
I find it much less trouble to forget about the emulator and the AVD, and just test on a connected actual Android device with an appropriate USB driver for that device. On Sunday, October 2, 2016 at 9:24:40 PM UTC-6, warren nazareno wrote: > > Hi guys. > > I'm new to android. > > I'm trying to configure the AVD. > But it says my CPU don't support. > So what are ways to fix this? > > Thanks in advance > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/dcbaa7da-bd96-4e84-baaa-7f177bc31b02%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Step Counter in Android KitKat
It depends on the app. Some step counters use only the accelerometers. But some might use the gyroscopes as well. But I would think that a properly designed app should report any missing hardware capabilities, or at least fail with an error message. On Tuesday, October 4, 2016 at 5:58:09 AM UTC-6, Naman Arora wrote: > > Some Android devices works step counter and step detector properly but not > all android devices, does it is based on gyroscope or accelerometer sensor > or both. > my phone have accelerometer sensor but step counter app will not work.Thank > you all for help! > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/eae0193a-401d-48fd-99e3-b35e21ff606c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Android Studio - can't see bottom of window
If the Windows display is set to the option of 125% (medium), vs. smaller (100%), the bottom part of the New Project wizard cannot be seen. It is essential to see it because that's where the "Next" button is to create a new project. None of the other windows in Android Studio have this problem. All the other windows are either adaptively sized or scrollable. Since I use the 125% display size option, I am forced to change my display options, log out of Windows, log back in (find all the desktop icons are moved around), create the new project, then change the display size option back to 125%, log off of Windows, and log back in. Does anyone know a better way to do this? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/4bde7c55-76b9-4a27-a9a3-a2c6129bc45e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Please ban those job postings!
The group rules say that job postings are considered spam and posters can be banned without warning. Moderators, please *do your job*. This group is being ruined by being flooded with job postings. It makes it very hard to even find the technical postings amidst all the spam, even if I never open them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/3f8ef6e1-ea67-461f-b25d-93447e9758c3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Problem with package installer's "Open" option
Immediately after installing my app (side-loaded APK file), the package installer gives the option of "Done" or "Open". If I select "Open", it will immediately launch my app's main activity. From that main activity in my app, I start a second activity with startActivityForResult. The second activity displays. Now I press "Home" to go to the device's home screen. So far all is working as it should. But now, I find the icon for my app and tap on that icon. What should I see? Well, I expect to see that second activity of my app, which is the state my app was in when I last left it by pressing "Home". But instead I see my app's main activity again. And if now press the system "Back" button, I do get back to that second activity, as if that second activity has launched the main activity. The "stack" of activities seems messed up. The reason I say this is due to the package installer is that if I try the same experiment, but instead of starting from a fresh install, I start from an initial launch from the device's home screen, everything behaves as it should. That is, I first see my main activity, I go to the second activity, I press Home, then I launch my app again, I see the second activity, just as I should. What the the reason for the different behavior when starting an app directly from the package installer? Are there two instances of my app for a while? Why should it behave differently based on how it was initially launched? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/82215977-def3-4c92-a248-ed730983887c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Why won't my app work on devices running 6.0?
I had a problem with 6.0 because I was using the Mac-ID of the wi-fi device to construct a unique ID for each specific device (It is the way my side-loaded app does licensing). Starting with 6.0, the MAC-ID is no longer available. The OS returns a constant with lots of zeroes. I had to scramble to come up with an alternate source for a unique device ID. On Thursday, May 19, 2016 at 8:24:03 AM UTC-6, michae...@trimble.com wrote: > > I have built an app using the 5.1 SDK and it is having problems running on > 6.0 devices. Any suggestions or fixes? > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/39ce0662-e229-44f4-86af-92befdade204%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] How to force any device to use the google USB driver
As I explained in another thread, I was having trouble debugging on a particular device - a Lenovo Tab 2 A8 tablet. After much searching, I found a way that worked in my case to make the Lenovo tablet use the google USB driver. Here is how I did it. If you find the google ADB USB driver in \ extras \ google \ usb_driver (in Windows) you will see a file called android_winusb.inf. If you edit this file with a text processor, like Notepad, you will find it has "sections" headed by things like [Google.NTx86] and [Google.NTamd64]. The items in that section are of the form: %SingleAdbInterface%= USB_Install, USB\VID_18D1_4E11 %CompositeAdbInterface% = USB_Install, USB\VID_18D1_4E12_01 (The above items describe a Google Nexus One). The VID and PID are codes that uniquely describe a particular USB device. Apparently, a USB device will only use the Google USB driver if the VID and PID appear in one of these lines. So I edited the android_winusb.inf file and added lines at the end of both the [Google.NTx86] and [Google.NTamd64] section that looked like this: ;Lenovo PTP (ADB Interface) %CompositeAdbInterface% = USB_Install, USB\VID_17EF_78DF_01 Keep in mind that if the Android SDK is in Program Files (x86) (which it usually is) you will need to run Notepad or whatever editor you use in administrator mode. Now this has a certain risk in that adding this to the INF file "forces" the system to accept this driver as the driver for the device. If the device is really not compatible with this driver, probably bad things will happen. But for me it worked out. The Lenovo tablet is compatible and I was able to debug in Android Studio using ADB. I still need to explain how I found out the VID and PID of the Lenovo tablet. You can find that out in the Windows device manager. Turn on USB debugging in the target Android device, and in the case of the Lenovo tablet, I also had to enable the PTP connection (as opposed to the MTP connection). The VID and PID change depending on these settings. Anyway, once you do these things, in the device manager, right click on the device (probably in "Other devices") and select properties, then details. Then in the drop-down box select Hardware IDs. That is where you can find the VID and PID for the device. After the INF file has been properly modified, you can go to the device manager again, and find the device and select "Update driver". Select the option to browse manually and browse to the Google USB driver folder containing that INF file you just modified. Then do the driver update. If all goes well, the driver will now be associated with the device, and ADB will work with it. I would much rather have downloaded an official driver for the Lenovo tablet, and indeed I did find many websites offering such a thing. But none of them were official, and all of them offered the driver in the form of an unsigned EXE file (i.e. virus city). I saw nothing on the Lenovo webite for this particular device, nor the Google website. I don't recommend the method I used, but if you want to take responsibility for these actions, this information will help you do it. -Robert Scott Hopkins, MN -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/465b0b80-2dc9-42bc-875f-f52049d3a78a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: How to debug on device with no USB driver
Well, I didn't find a way to debug without a USB driver, but I did find a way to get the Lenovo tablet to use the Google USB driver. See the other thread I will post shortly on how that can be done. -Robert Scott Hopkins, MN On Monday, March 28, 2016 at 11:35:30 AM UTC-6, RLScott wrote: > > On one particular device - a Lenovo tablet running Android 5.0 - my app > crashes on launch. On every other device I own, the app runs fine. > Unfortunately there is no OEM USB driver for debugging, so the only way I > have of running my app is making an APK file and copying it over and > installing and running on the device. Is there any logging facility or > some other debugging method I could use in this context? I have no idea > why my app is crashing on this device, and no way to set breakpoints or > anything nice like that. > > -Robert Scott > Hopkins, MN > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/ec72b23e-1cf4-4282-b1d0-a74ba4c0341b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] How to debug on device with no USB driver
On one particular device - a Lenovo tablet running Android 5.0 - my app crashes on launch. On every other device I own, the app runs fine. Unfortunately there is no OEM USB driver for debugging, so the only way I have of running my app is making an APK file and copying it over and installing and running on the device. Is there any logging facility or some other debugging method I could use in this context? I have no idea why my app is crashing on this device, and no way to set breakpoints or anything nice like that. -Robert Scott Hopkins, MN -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/78707994-ca49-4f17-96ba-258fc4adc5b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Updating the UI from a callback
OK, I think I figured it out. When the AlertDialog is created, I use: numFoundDisplay = (TextView)layout.findViewById(R.id.numFound); to get a reference to that TextView in the AlertDialog. That reference (numFoundDisplay) is owned by the Activity, and as long as that Activity lives and does not null out that reference, Android will not deallocate that TextView within the AlertDialog, even after the AlertDialog has been dismissed. So the TextView, as an object in memory, will continue to exist, and it will be valid to call setText() on that reference, even after the AlertDialog has been dismissed, because the Activity still holds a strong reference to that TextView. So if I use a Handler and a Runnable to update the TextView asynchronously, there will not be a crash or anything. The setText() will just be ineffective because the TextView is no longer visible. Do I have that right? -Robert Scott Hopkins, MN On Thursday, March 24, 2016 at 8:38:03 PM UTC-6, RLScott wrote: > > What is the correct way to update a TextView after a callback in the > following scenario: > > I have an activity that extends ListActivity. At some point that > activity creates an AlertDialog to allow the user the option of filtering > the list for items that contain a certain String (because the unfiltered > list might be too long to scroll through it conveniently). My AlertDialog > has, in addition to an OK and Cancel button, an EditText so the user can > enter the String to use for filtering, and two radio buttons to select > whether we should filter for list items that start with the specified > String or merely contain the specified String. I have listeners set up for > any changes to the EditText or RadioButtons so that I can cause the list to > be reloaded based on the revised filtering criteria. All this is working > fine with no problems. I can see the list changing behind the AlertDialog > as I enter characters into the EditText. > > The problem is this. I also want to have a TextView that displays "(X > items found)" after each reloading of the list, so the user can know when > he has sufficiently narrowed the search so he can quit the AlertDialog and > then pick from the (reduced) set of items now in the list. One other > complication is that the reloading of the list involves a callback on a > worker thread. You see, the list is a list of Dropbox files, and the > asynchronous load is necessary because it might involve an Internet > access. The callback is actually from a library provided by Dropbox. > Therefore the place where the reloading (and item counting) is done is not > the UI thread, so I can't update a TextView from there. I am familiar with > Handlers and posting from threads, but there is a problem with that too. > The Handler would be owned by the Activity, not by the AlertDialog, which > could be dismissed before the asynchronous reload occurs. Will there be a > problem if a post is made to start a Runnable that updates the TextView > that was in the AlertDialog if that AlertDialog, and therefore the TextView > inside it, has been destroyed? > > What if I define a strong reference in the Activity to the TextView, and > the Runnable that is triggered by the asynchronous Dropbox operation just > calls setText on that reference? Will that do anything bad if the Runnable > is invoked after the AlertDialog is dismissed? What is the clean way of > doing this? > > -Robert Scott > Hopkins, MN > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/18bd6847-7e5b-4586-aadb-fa77d333810c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Updating the UI from a callback
What is the correct way to update a TextView after a callback in the following scenario: I have an activity that extends ListActivity. At some point that activity creates an AlertDialog to allow the user the option of filtering the list for items that contain a certain String (because the unfiltered list might be too long to scroll through it conveniently). My AlertDialog has, in addition to an OK and Cancel button, an EditText so the user can enter the String to use for filtering, and two radio buttons to select whether we should filter for list items that start with the specified String or merely contain the specified String. I have listeners set up for any changes to the EditText or RadioButtons so that I can cause the list to be reloaded based on the revised filtering criteria. All this is working fine with no problems. I can see the list changing behind the AlertDialog as I enter characters into the EditText. The problem is this. I also want to have a TextView that displays "(X items found)" after each reloading of the list, so the user can know when he has sufficiently narrowed the search so he can quit the AlertDialog and then pick from the (reduced) set of items now in the list. One other complication is that the reloading of the list involves a callback on a worker thread. You see, the list is a list of Dropbox files, and the asynchronous load is necessary because it might involve an Internet access. The callback is actually from a library provided by Dropbox. Therefore the place where the reloading (and item counting) is done is not the UI thread, so I can't update a TextView from there. I am familiar with Handlers and posting from threads, but there is a problem with that too. The Handler would be owned by the Activity, not by the AlertDialog, which could be dismissed before the asynchronous reload occurs. Will there be a problem if a post is made to start a Runnable that updates the TextView that was in the AlertDialog if that AlertDialog, and therefore the TextView inside it, has been destroyed? What if I define a strong reference in the Activity to the TextView, and the Runnable that is triggered by the asynchronous Dropbox operation just calls setText on that reference? Will that do anything bad if the Runnable is invoked after the AlertDialog is dismissed? What is the clean way of doing this? -Robert Scott Hopkins, MN -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/e79ac507-3ba7-4fca-8ab7-456abef374d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: bluetooth: paired bluetooth devices list
Get the list of paired bluetooth devices like this:
private final BluetoothAdapter mAdapter = BluetoothAdapter.getDefaultAdapter();
Set pairedDevices = mAdapter.getBondedDevices();
int numberOfDevices = pairedDevices.size();
if (numberOfDevices > 0) {
for (BluetoothDevice device : pairedDevices) {
String devAddr = device.getAddress();
if(..whatever selection criteria you want..)
{
//..do something with that device
}
}
}
-Robert Scott
Hopkins, MN
On Monday, February 15, 2016 at 5:54:42 PM UTC-6, borzack wrote:
>
> Hi All,
> I need know where android save the paired bluetooht list.
> The reason is that I've two devices where one of this can receive info
> about second device only by wifi/sms but no by bluetooth, so I can pair
> them only managing the paired devices bluetooth list.
> Someone can help me?
>
> thanks in advanced
>
>
--
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/android-developers/5f7fbf38-fbc2-4697-b179-fc90f0ff9b14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Proguard complains about duplicate definitions of class was removed
New information: The messages I reported do not appear to be the result of my previous attempt at adding something from org.apach.http... I just imported another project from Eclipse to Android Studio, and in this project I never message around with HTTP stuff. Yet the same message appeared. Here is what Proguard reports in the Gradle console just before those "duplicate definition" messages: Reading program jar [C:\Swdev\Android\sdk\extras\android\m2repository\com\android\support\support-annotations\23.1.1\support-annotations-23.1.1.jar] (filtered) Reading program jar [C:\Users\Bob\AndroidProj\as\Cadence\app\build\intermediates\exploded-aar\com.android.support\appcompat-v7\23.1.1\jars\classes.jar] (filtered) Reading program jar [C:\Users\Bob\AndroidProj\as\Cadence\app\build\intermediates\exploded-aar\com.android.support\support-v4\23.1.1\jars\classes.jar] (filtered) Reading program jar [C:\Users\Bob\AndroidProj\as\Cadence\app\build\intermediates\exploded-aar\com.android.support\support-v4\23.1.1\jars\libs\internal_impl-23.1.1.jar] (filtered) Reading program directory [C:\Users\Bob\AndroidProj\as\Cadence\app\build\intermediates\classes\release] (filtered) Reading library jar [C:\Swdev\Android\sdk\platforms\android-23\android.jar] Reading library jar [C:\Swdev\Android\sdk\platforms\android-23\optional\org.apache.http.legacy.jar] I still don't see why there are duplicate definitions. -Robert Scott Hopkins, MN On Monday, February 15, 2016 at 11:20:29 AM UTC-6, RLScott wrote: > > I briefly added a HTTP library from org.apache.http... to try some things > out, and now I want to remove it as I no longer reference it in my code. I > removed the reference in the Project app module Dependencies and deleted > the apache module itself. > > Now the project builds without errors, as long as I don't enable Proguard > in my gradle file. If I set "minifyEnabled true" in the app > build.gradle, I get the following message in the gradle console: > > Note: duplicate definition of library class [android.net.http.SslError] > Note: duplicate definition of library class > [android.net.http.SslCertificate] > Note: duplicate definition of library class > [android.net.http.SslCertificate$DName] > Note: duplicate definition of library class > [org.apache.http.conn.scheme.HostNameResolver] > Note: duplicate definition of library class > [org.apache.http.conn.scheme.SocketFactory] > Note: duplicate definition of library class > [org.apache.http.conn.ConnectTimeoutException] > Note: duplicate definition of library class > [org.apache.http.params.HttpParams] > > I think these were are left-over from my brief experiment with apach > http. I would like to get rid of these messages, even though they don't > seem to be harming the final APK file, which still runs fine. Is there > anywhere else I should look for references to this HTTP library? > > > -Robert Scott > Hopkins, MN > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/b3d67b5b-4173-400a-80b6-f4d45773d18a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Proguard complains about duplicate definitions of class was removed
I briefly added a HTTP library from org.apache.http... to try some things out, and now I want to remove it as I no longer reference it in my code. I removed the reference in the Project app module Dependencies and deleted the apache module itself. Now the project builds without errors, as long as I don't enable Proguard in my gradle file. If I set "minifyEnabled true" in the app build.gradle, I get the following message in the gradle console: Note: duplicate definition of library class [android.net.http.SslError] Note: duplicate definition of library class [android.net.http.SslCertificate] Note: duplicate definition of library class [android.net.http.SslCertificate$DName] Note: duplicate definition of library class [org.apache.http.conn.scheme.HostNameResolver] Note: duplicate definition of library class [org.apache.http.conn.scheme.SocketFactory] Note: duplicate definition of library class [org.apache.http.conn.ConnectTimeoutException] Note: duplicate definition of library class [org.apache.http.params.HttpParams] I think these were are left-over from my brief experiment with apach http. I would like to get rid of these messages, even though they don't seem to be harming the final APK file, which still runs fine. Is there anywhere else I should look for references to this HTTP library? -Robert Scott Hopkins, MN -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/80f8eb35-3f57-4987-b75a-72bf05b59f2c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Installing Android Studio without hurting Eclipse
I have Eclipse on my Windows 7 system and it is working fine (well, as fine as Eclipse is capable of running..) I want to try changing over to Android Studio, but I don't want to burn my bridges behind me. Can the Android Studio installation be done in such as way that there is no possible danger to my existing Eclipse installation and projects so I could return to Eclipse at any time? (And don't say "re-install Eclipse"). I am worried about things like a common Java or Android SDK component. If there is any chance of messing up my Eclipse installation, I might consider buying a new computer and begin a changeover to Windows 10. -Robert Scott Hopkins, MN -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/832f93b6-99af-4a1f-b7ba-1475636b05a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Re: Audio recording problem - fake sample rate
OK, I finally got myself a cheap LG G3 from eBay and did some testing. The situation is not exactly as I described before. Here is what is really happening. I tested my app with a sine-wave tone generator. When the tone generator is below about 3700 Hz, the spectrum displayed in my app shows just one peak at the desired frequency. As the frequency of the tone generator increases toward 4000 Hz, a very tiny mirror image peak begins to appear on the other side of 4000 Hz. It gradually gains in amplitude until by 3958 Hz, the amplitude of the image peak is actually a bit higher than the peak at the correct frequency. As the tone goes above 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in amplitude as the tone frequency increases. I ran the tone frequency up to 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image peak. This entirely destroys my supposition that this phone is initially sampling at 8000 Hz and then up-sampling to 44100, because if it were, there would be no way to show a single peak at 4698 Hz with no image peak, right? I mean, the information that discriminates between 4698 and 3302 is totally destroyed if the audio is initially sampled at 8000 Hz. But something is going on in the phone's audio system that introduces this image around 4000 Hz. Could it be some sort of hetrodyning? I know in single sideband radio there are ways to invert the audio spectrum if the detection carrier is set on the wrong side of the signal. But why would things return to normal for tones well away from 4000 Hz? -Robert Scott Hopkins, MN On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote: > > Perhaps you can post your code, and we can take a look to see if we see > anything that might be causing this problem? Otherwise, if it really is a > firmware "feature" in those two devices, I don't see any good alternatives > other than a) marking your APK as incompatible with those devices in Google > Play, or b) doing some DSP in your software to detect the condition and > work around it somehow. If it were me, I would obtain a G3 and start > testing ... > > > > On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers < > android-d...@googlegroups.com > wrote: > >> The theory says if the initial hardware sampling is done at 8000 samples >> per second, the aliasing is already "frozen" into the sampled data. You can >> see that by observing that 4100 Hz and 3900 Hz look exactly the same - >> produce exactly the same samples - after they are sampled at 8000 samples >> per second. No amount of digital signal processing after that point can >> distinguish the two cases, so the aliasing in the up-sampled FFT is >> inevitable, with or without windowing. >> >> I may yet get a G3 on Ebay as you say, but I was hoping for some >> independent confirmation of this problem with a codebase that had nothing >> in common with my code, in case there is something I am doing in the code >> that is making the difference. So if you have an app that processes sound >> and can detect frequency content above 4000 Hz, just have someone with one >> of these failing devices go to piano and play the highest "B". That is >> usually about 4019 Hz. If the device is failing as I predict, there should >> also be an indication of a tone at 3981 Hz. >> >> Robert Scott >> Hopkins, MN >> >> On Sunday, January 31, 2016 at 1:39:58 PM UTC-6, Julian Bunn wrote: >> >>> If you are only getting 8000 sps then even with interpolation to 44100 >>> you would never see any signal above 4000Hz in an FFT, right? Are you >>> windowing the FFT? >>> >>> If there are truly problems like this with the audio firmware on the LG >>> G3 and Nexus 7, I haven't heard any reports from my users about them. >>> That's not to say there can't be an issue, of course :-) If I were you, I >>> would obtain a cheap used G3 on Ebay to test with. >>> >>> >>> >>> On Saturday, January 30, 2016 at 6:13:08 PM UTC-8, RLScott wrote: >>>> >>>> But are you sure you are getting the sample rate you asked for? How >>>> would you know? As you can see from my very first posting, all the checks >>>> you are doing here work fine for me too, and I actually do get the number >>>> of samples per second I ask for. But they are not true samples. They >>>> have >>>> been faked by up-sampling. The system takes 8000 samples per second and >>>> then duplicates each sample enough times to make up 44100 or 22050 or >>>> whatever. But I know those samples are not
Re: [android-developers] Re: Audio recording problem - fake sample rate
No, I don't know anything about the "VOICE_RECOGNITION" mic stream. I am just using the standard audio input stream set up with the code I posted earlier. However someone in a DSP forum told me that the LG G3 has two mics, one in front and one in back, and they do some DSP with those two data streams to realize noise cancellation. This might be some artifact of that operation. -Robert Scott Hopkins, MN On Tuesday, February 9, 2016 at 1:20:12 PM UTC-6, Julian Bunn wrote: > > That is very curious! Are you using the "VOICE_RECOGNITION" mic stream? > I'm wondering if there is some sort of odd DSP filtering being applied in > the firmware. > > On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers < > android-d...@googlegroups.com > wrote: > >> OK, I finally got myself a cheap LG G3 from eBay and did some testing. >> The situation is not exactly as I described before. Here is what is really >> happening. I tested my app with a sine-wave tone generator. >> >> When the tone generator is below about 3700 Hz, the spectrum displayed in >> my app shows just one peak at the desired frequency. As the frequency of >> the tone generator increases toward 4000 Hz, a very tiny mirror image peak >> begins to appear on the other side of 4000 Hz. It gradually gains in >> amplitude until by 3958 Hz, the amplitude of the image peak is actually a >> bit higher than the peak at the correct frequency. As the tone goes above >> 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in >> amplitude as the tone frequency increases. I ran the tone frequency up to >> 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image >> peak. This entirely destroys my supposition that this phone is initially >> sampling at 8000 Hz and then up-sampling to 44100, because if it were, >> there would be no way to show a single peak at 4698 Hz with no image peak, >> right? I mean, the information that discriminates between 4698 and 3302 is >> totally destroyed if the audio is initially sampled at 8000 Hz. >> >> But something is going on in the phone's audio system that introduces >> this image around 4000 Hz. Could it be some sort of hetrodyning? I know >> in single sideband radio there are ways to invert the audio spectrum if the >> detection carrier is set on the wrong side of the signal. But why would >> things return to normal for tones well away from 4000 Hz? >> >> -Robert Scott >> Hopkins, MN >> >> >> On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote: >>> >>> Perhaps you can post your code, and we can take a look to see if we see >>> anything that might be causing this problem? Otherwise, if it really is a >>> firmware "feature" in those two devices, I don't see any good alternatives >>> other than a) marking your APK as incompatible with those devices in Google >>> Play, or b) doing some DSP in your software to detect the condition and >>> work around it somehow. If it were me, I would obtain a G3 and start >>> testing ... >>> >>> >>> >>> On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers < >>> android-d...@googlegroups.com> wrote: >>> >>>> The theory says if the initial hardware sampling is done at 8000 >>>> samples per second, the aliasing is already "frozen" into the sampled >>>> data. >>>> You can see that by observing that 4100 Hz and 3900 Hz look exactly the >>>> same - produce exactly the same samples - after they are sampled at 8000 >>>> samples per second. No amount of digital signal processing after that >>>> point can distinguish the two cases, so the aliasing in the up-sampled FFT >>>> is inevitable, with or without windowing. >>>> >>>> I may yet get a G3 on Ebay as you say, but I was hoping for some >>>> independent confirmation of this problem with a codebase that had nothing >>>> in common with my code, in case there is something I am doing in the code >>>> that is making the difference. So if you have an app that processes sound >>>> and can detect frequency content above 4000 Hz, just have someone with one >>>> of these failing devices go to piano and play the highest "B". That is >>>> usually about 4019 Hz. If the device is failing as I predict, there >>>> should >>>> also be an indication of a tone at 3981 Hz. >>>> >>>> Robert Scott >>>> Hopkins, MN >>
Re: [android-developers] Re: Audio recording problem - fake sample rate
New evidence: I adjusted the frequency of the tone generator to give the worst-case spectrum imaging with two peaks of the same amplitude in my app. That turned out to be 3945 Hz with an image at 4055 Hz. Then I closed my app and opened the built-in Voice Recorder app. I recorded that pure tone with the Voice Recorder. When I played it back it had a nasty double-tones-close-together sound. It was nothing like the pure tone I had recorded, but was exactly what I would expect if the Voice Recorder app as getting the same imaging artifact as my app - and it was! So this is not a coding problem on my end. It is a deep inherent problem with this LG G3 phone. I guess there is nothing more I can do. -Robert Scott Hopkins, MN On Tuesday, February 9, 2016 at 1:20:12 PM UTC-6, Julian Bunn wrote: > > That is very curious! Are you using the "VOICE_RECOGNITION" mic stream? > I'm wondering if there is some sort of odd DSP filtering being applied in > the firmware. > > On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers < > android-d...@googlegroups.com > wrote: > >> OK, I finally got myself a cheap LG G3 from eBay and did some testing. >> The situation is not exactly as I described before. Here is what is really >> happening. I tested my app with a sine-wave tone generator. >> >> When the tone generator is below about 3700 Hz, the spectrum displayed in >> my app shows just one peak at the desired frequency. As the frequency of >> the tone generator increases toward 4000 Hz, a very tiny mirror image peak >> begins to appear on the other side of 4000 Hz. It gradually gains in >> amplitude until by 3958 Hz, the amplitude of the image peak is actually a >> bit higher than the peak at the correct frequency. As the tone goes above >> 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in >> amplitude as the tone frequency increases. I ran the tone frequency up to >> 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image >> peak. This entirely destroys my supposition that this phone is initially >> sampling at 8000 Hz and then up-sampling to 44100, because if it were, >> there would be no way to show a single peak at 4698 Hz with no image peak, >> right? I mean, the information that discriminates between 4698 and 3302 is >> totally destroyed if the audio is initially sampled at 8000 Hz. >> >> But something is going on in the phone's audio system that introduces >> this image around 4000 Hz. Could it be some sort of hetrodyning? I know >> in single sideband radio there are ways to invert the audio spectrum if the >> detection carrier is set on the wrong side of the signal. But why would >> things return to normal for tones well away from 4000 Hz? >> >> -Robert Scott >> Hopkins, MN >> >> >> On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote: >>> >>> Perhaps you can post your code, and we can take a look to see if we see >>> anything that might be causing this problem? Otherwise, if it really is a >>> firmware "feature" in those two devices, I don't see any good alternatives >>> other than a) marking your APK as incompatible with those devices in Google >>> Play, or b) doing some DSP in your software to detect the condition and >>> work around it somehow. If it were me, I would obtain a G3 and start >>> testing ... >>> >>> >>> >>> On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers < >>> android-d...@googlegroups.com> wrote: >>> >>>> The theory says if the initial hardware sampling is done at 8000 >>>> samples per second, the aliasing is already "frozen" into the sampled >>>> data. >>>> You can see that by observing that 4100 Hz and 3900 Hz look exactly the >>>> same - produce exactly the same samples - after they are sampled at 8000 >>>> samples per second. No amount of digital signal processing after that >>>> point can distinguish the two cases, so the aliasing in the up-sampled FFT >>>> is inevitable, with or without windowing. >>>> >>>> I may yet get a G3 on Ebay as you say, but I was hoping for some >>>> independent confirmation of this problem with a codebase that had nothing >>>> in common with my code, in case there is something I am doing in the code >>>> that is making the difference. So if you have an app that processes sound >>>> and can detect frequency content above 4000 Hz, just have someone with one >>>> of th
Re: [android-developers] Re: Audio recording problem - fake sample rate
Well if that don't beat all! It worked! I just replaced MediaRecorder.AudioSource.MIC with MediaRecorder.AudioSource.VOICE_RECOGNITION in my "new AudioRecord(...)" and now the artifacts around 4000 Hz are gone. I can sweep a tone above and below 4kHz and all I get is one nice peak in the FFT. Thanks a lot for the suggestion. Now I just need to test and see if my app will suffer due to the loss AGC. -Robert Scott Hopkins, MN On Tuesday, February 9, 2016 at 5:29:00 PM UTC-6, Julian Bunn wrote: > > I think that you should perhaps use the VOICE_RECOGNITION stream which is > *supposed* to be devoid of filtering and AGC etc.. > > > http://developer.android.com/reference/android/media/MediaRecorder.AudioSource.html#VOICE_RECOGNITION > > It's possible to select which Mic is being used, too. (My app offers a > choice between "FRONT" and "Main" mics - the Front one is typically next to > the front facing camera lens, and makes sense for video ...) > > > > On Tue, Feb 9, 2016 at 1:19 PM, 'RLScott' via Android Developers < > android-d...@googlegroups.com > wrote: > >> No, I don't know anything about the "VOICE_RECOGNITION" mic stream. I am >> just using the standard audio input stream set up with the code I posted >> earlier. However someone in a DSP forum told me that the LG G3 has two >> mics, one in front and one in back, and they do some DSP with those two >> data streams to realize noise cancellation. This might be some artifact of >> that operation. >> >> -Robert Scott >> Hopkins, MN >> >> On Tuesday, February 9, 2016 at 1:20:12 PM UTC-6, Julian Bunn wrote: >>> >>> That is very curious! Are you using the "VOICE_RECOGNITION" mic stream? >>> I'm wondering if there is some sort of odd DSP filtering being applied in >>> the firmware. >>> >>> On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers < >>> android-d...@googlegroups.com> wrote: >>> >>>> OK, I finally got myself a cheap LG G3 from eBay and did some testing. >>>> The situation is not exactly as I described before. Here is what is >>>> really >>>> happening. I tested my app with a sine-wave tone generator. >>>> >>>> When the tone generator is below about 3700 Hz, the spectrum displayed >>>> in my app shows just one peak at the desired frequency. As the frequency >>>> of the tone generator increases toward 4000 Hz, a very tiny mirror image >>>> peak begins to appear on the other side of 4000 Hz. It gradually gains in >>>> amplitude until by 3958 Hz, the amplitude of the image peak is actually a >>>> bit higher than the peak at the correct frequency. As the tone goes above >>>> 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in >>>> amplitude as the tone frequency increases. I ran the tone frequency up to >>>> 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image >>>> peak. This entirely destroys my supposition that this phone is initially >>>> sampling at 8000 Hz and then up-sampling to 44100, because if it were, >>>> there would be no way to show a single peak at 4698 Hz with no image peak, >>>> right? I mean, the information that discriminates between 4698 and 3302 >>>> is >>>> totally destroyed if the audio is initially sampled at 8000 Hz. >>>> >>>> But something is going on in the phone's audio system that introduces >>>> this image around 4000 Hz. Could it be some sort of hetrodyning? I know >>>> in single sideband radio there are ways to invert the audio spectrum if >>>> the >>>> detection carrier is set on the wrong side of the signal. But why would >>>> things return to normal for tones well away from 4000 Hz? >>>> >>>> -Robert Scott >>>> Hopkins, MN >>>> >>>> >>>> On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote: >>>>> >>>>> Perhaps you can post your code, and we can take a look to see if we >>>>> see anything that might be causing this problem? Otherwise, if it really >>>>> is >>>>> a firmware "feature" in those two devices, I don't see any good >>>>> alternatives other than a) marking your APK as incompatible with those >>>>> devices in Google Play, or b) doing some DSP in your software to detect >>>>> the >>>>> condition and work around
[android-developers] Re: Audio recording problem - fake sample rate
On Sunday, January 31, 2016 at 1:39:58 PM UTC-6, Julian Bunn wrote:
>
> If you are only getting 8000 sps then even with interpolation to 44100 you
> would never see any signal above 4000Hz in an FFT, right? Are you windowing
> the FFT?
>
No, the theory says if the initial hardware sampling is done at 8000
samples per second, the aliasing is already "frozen" into the sampled data.
You can see that by observing that 4100 Hz and 3900 Hz look exactly the
same - produce exactly the same samples - after they are sampled at 8000
samples per second. No amount of digital signal processing after that
point can distinguish the two cases, so the aliasing in the up-sampled FFT
is inevitable, with or without windowing.
I may yet get a G3 on Ebay as you say, but I was hoping for some
independent confirmation of this problem with a codebase that had nothing
in common with my code, in case there is something I am doing in the code
that is making the difference. So if you have an app that processes sound
and can detect frequency content above 4000 Hz, just have someone with one
of these failing devices go to piano and play the highest "B". That is
usually about 4263 Hz. If the device is failing as I predict, there should
also be an indication of a tone at 3737 Hz.
>
>
>
>
> On Saturday, January 30, 2016 at 6:13:08 PM UTC-8, RLScott wrote:
>>
>> But are you sure you are getting the sample rate you asked for? How
>> would you know? As you can see from my very first posting, all the checks
>> you are doing here work fine for me too, and I actually do get the number
>> of samples per second I ask for. But they are not true samples. They have
>> been faked by up-sampling. The system takes 8000 samples per second and
>> then duplicates each sample enough times to make up 44100 or 22050 or
>> whatever. But I know those samples are not true samples because I see
>> aliasing around 4000 Hz in the frequency spectrum. Unless you specifically
>> look for this problem by testing with a pure tone above 4000 Hz and analyze
>> with an FFT and look for aliasing below 4000 Hz, everything will appear
>> fine. Again this only happens on a very few models - specifically the LG
>> G3 and the Asus Nexus 7.
>>
>> On Wednesday, January 27, 2016 at 10:57:45 AM UTC-6, Julian Bunn wrote:
>>>
>>> Yes, that looks fine to me ... In case it helps, here is a snippet of
>>> what I do to check a samplerate is going to work:
>>>
>>> minBuffer = AudioRecord
>>> .getMinBufferSize(rate, config, encoding);
>>> if (minBuffer != AudioRecord.ERROR_BAD_VALUE
>>> && minBuffer != AudioRecord.ERROR) {
>>>boolean bGood = true;
>>>try {
>>> audio = new AudioRecord(audioSource, rate, config,
>>> encoding, minBuffer);
>>> int istate = audio.getState();
>>> if (istate != AudioRecord.STATE_INITIALIZED)
>>> bGood = false;
>>>} catch (Exception e) {
>>> bGood = false;
>>>}
>>>audio.release();
>>>audio = null;
>>>if (bGood)
>>> return rate;
>>>
>>>
>>> On Tuesday, January 26, 2016 at 12:49:46 PM UTC-8, RLScott wrote:
I am calling
AudioRecord.getMinBufferSize(44100,AudioFormat.CHANNEL_IN_MONO,AudioFormat.ENCODING_PCM_16BIT)
and using the returned minAudioRecordBufSize in
new AudioRecord(MediaRecorder.AudioSource.MIC,
44100,AudioFormat.CHANNEL_IN_MONO,
AudioFormat.ENCODING_PCM_16BIT,
minAudioRecordBufSize);
Is that sizing the buffers correctly?
Thanks for the offer for the enumeration app, but I do not have a
failing device at my disposal. Only a few devices are failing, and they
are all owned by my customers. I can't ask too much of them in the way of
debugging help.
On Friday, January 15, 2016 at 1:34:15 AM UTC-6, Julian Bunn wrote:
>
> Make sure you are sizing the buffers correctly i.e. respecting the
> minimum recording buffer size (in bytes) required. If you don't then I
> believe the system will drop you down to 8kHz sample rate, which is what
> you are seeing (I think?).
>
>
> On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott
> wrote:
>>
>> I first call *AudioRecord.getMinBufferSize(22050...* If this
>> returns an error (<1) then I call
>> *AudioRecord.getMinBufferSize(44100...* Whichever one of these
>> calls succeeds, I use that rate in my call to "*new
>> AudioRecord(..,sampleRate..)*"
>>
>> I don't actually have one of these misbehaving devices, so my
>> experiments so far have been with the help of my customers.
>>
>> -Robert Scott
>> Hopkins, MN
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
[android-developers] Re: Audio recording problem - fake sample rate
The theory says if the initial hardware sampling is done at 8000 samples
per second, the aliasing is already "frozen" into the sampled data. You can
see that by observing that 4100 Hz and 3900 Hz look exactly the same -
produce exactly the same samples - after they are sampled at 8000 samples
per second. No amount of digital signal processing after that point can
distinguish the two cases, so the aliasing in the up-sampled FFT is
inevitable, with or without windowing.
I may yet get a G3 on Ebay as you say, but I was hoping for some
independent confirmation of this problem with a codebase that had nothing
in common with my code, in case there is something I am doing in the code
that is making the difference. So if you have an app that processes sound
and can detect frequency content above 4000 Hz, just have someone with one
of these failing devices go to piano and play the highest "B". That is
usually about 4019 Hz. If the device is failing as I predict, there should
also be an indication of a tone at 3981 Hz.
Robert Scott
Hopkins, MN
On Sunday, January 31, 2016 at 1:39:58 PM UTC-6, Julian Bunn wrote:
>
> If you are only getting 8000 sps then even with interpolation to 44100 you
> would never see any signal above 4000Hz in an FFT, right? Are you windowing
> the FFT?
>
> If there are truly problems like this with the audio firmware on the LG G3
> and Nexus 7, I haven't heard any reports from my users about them. That's
> not to say there can't be an issue, of course :-) If I were you, I would
> obtain a cheap used G3 on Ebay to test with.
>
>
>
> On Saturday, January 30, 2016 at 6:13:08 PM UTC-8, RLScott wrote:
>>
>> But are you sure you are getting the sample rate you asked for? How
>> would you know? As you can see from my very first posting, all the checks
>> you are doing here work fine for me too, and I actually do get the number
>> of samples per second I ask for. But they are not true samples. They have
>> been faked by up-sampling. The system takes 8000 samples per second and
>> then duplicates each sample enough times to make up 44100 or 22050 or
>> whatever. But I know those samples are not true samples because I see
>> aliasing around 4000 Hz in the frequency spectrum. Unless you specifically
>> look for this problem by testing with a pure tone above 4000 Hz and analyze
>> with an FFT and look for aliasing below 4000 Hz, everything will appear
>> fine. Again this only happens on a very few models - specifically the LG
>> G3 and the Asus Nexus 7.
>>
>> On Wednesday, January 27, 2016 at 10:57:45 AM UTC-6, Julian Bunn wrote:
>>>
>>> Yes, that looks fine to me ... In case it helps, here is a snippet of
>>> what I do to check a samplerate is going to work:
>>>
>>> minBuffer = AudioRecord
>>> .getMinBufferSize(rate, config, encoding);
>>> if (minBuffer != AudioRecord.ERROR_BAD_VALUE
>>> && minBuffer != AudioRecord.ERROR) {
>>>boolean bGood = true;
>>>try {
>>> audio = new AudioRecord(audioSource, rate, config,
>>> encoding, minBuffer);
>>> int istate = audio.getState();
>>> if (istate != AudioRecord.STATE_INITIALIZED)
>>> bGood = false;
>>>} catch (Exception e) {
>>> bGood = false;
>>>}
>>>audio.release();
>>>audio = null;
>>>if (bGood)
>>> return rate;
>>>
>>>
>>> On Tuesday, January 26, 2016 at 12:49:46 PM UTC-8, RLScott wrote:
I am calling
AudioRecord.getMinBufferSize(44100,AudioFormat.CHANNEL_IN_MONO,AudioFormat.ENCODING_PCM_16BIT)
and using the returned minAudioRecordBufSize in
new AudioRecord(MediaRecorder.AudioSource.MIC,
44100,AudioFormat.CHANNEL_IN_MONO,
AudioFormat.ENCODING_PCM_16BIT,
minAudioRecordBufSize);
Is that sizing the buffers correctly?
Thanks for the offer for the enumeration app, but I do not have a
failing device at my disposal. Only a few devices are failing, and they
are all owned by my customers. I can't ask too much of them in the way of
debugging help.
On Friday, January 15, 2016 at 1:34:15 AM UTC-6, Julian Bunn wrote:
>
> Make sure you are sizing the buffers correctly i.e. respecting the
> minimum recording buffer size (in bytes) required. If you don't then I
> believe the system will drop you down to 8kHz sample rate, which is what
> you are seeing (I think?).
>
>
> On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott
> wrote:
>>
>> I first call *AudioRecord.getMinBufferSize(22050...* If this
>> returns an error (<1) then I call
>> *AudioRecord.getMinBufferSize(44100...* Whichever one of these
>> calls succeeds, I use that rate in my call to "*new
>> AudioRecord(..,sampleRate..)*"
>>
>> I don't actually have one of these misbehaving devices, so my
>> experiments so far have been with the help of my
[android-developers] Re: Audio recording problem - fake sample rate
But are you sure you are getting the sample rate you asked for? How would
you know? As you can see from my very first posting, all the checks you
are doing here work fine for me too, and I actually do get the number of
samples per second I ask for. But they are not true samples. They have
been faked by up-sampling. The system takes 8000 samples per second and
then duplicates each sample enough times to make up 44100 or 22050 or
whatever. But I know those samples are not true samples because I see
aliasing around 4000 Hz in the frequency spectrum. Unless you specifically
look for this problem by testing with a pure tone above 4000 Hz and analyze
with an FFT and look for aliasing below 4000 Hz, everything will appear
fine. Again this only happens on a very few models - specifically the LG
G3 and the Asus Nexus 7.
On Wednesday, January 27, 2016 at 10:57:45 AM UTC-6, Julian Bunn wrote:
>
> Yes, that looks fine to me ... In case it helps, here is a snippet of what
> I do to check a samplerate is going to work:
>
> minBuffer = AudioRecord
> .getMinBufferSize(rate, config, encoding);
> if (minBuffer != AudioRecord.ERROR_BAD_VALUE
> && minBuffer != AudioRecord.ERROR) {
>boolean bGood = true;
>try {
> audio = new AudioRecord(audioSource, rate, config,
> encoding, minBuffer);
> int istate = audio.getState();
> if (istate != AudioRecord.STATE_INITIALIZED)
> bGood = false;
>} catch (Exception e) {
> bGood = false;
>}
>audio.release();
>audio = null;
>if (bGood)
> return rate;
>
>
> On Tuesday, January 26, 2016 at 12:49:46 PM UTC-8, RLScott wrote:
>>
>> I am calling
>> AudioRecord.getMinBufferSize(44100,AudioFormat.CHANNEL_IN_MONO,AudioFormat.ENCODING_PCM_16BIT)
>>
>> and using the returned minAudioRecordBufSize in
>>
>> new AudioRecord(MediaRecorder.AudioSource.MIC,
>> 44100,AudioFormat.CHANNEL_IN_MONO,
>>AudioFormat.ENCODING_PCM_16BIT, minAudioRecordBufSize);
>>
>> Is that sizing the buffers correctly?
>>
>> Thanks for the offer for the enumeration app, but I do not have a failing
>> device at my disposal. Only a few devices are failing, and they are all
>> owned by my customers. I can't ask too much of them in the way of
>> debugging help.
>>
>>
>> On Friday, January 15, 2016 at 1:34:15 AM UTC-6, Julian Bunn wrote:
>>>
>>> Make sure you are sizing the buffers correctly i.e. respecting the
>>> minimum recording buffer size (in bytes) required. If you don't then I
>>> believe the system will drop you down to 8kHz sample rate, which is what
>>> you are seeing (I think?).
>>>
>>>
>>> On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott wrote:
I first call *AudioRecord.getMinBufferSize(22050...* If this returns
an error (<1) then I call *AudioRecord.getMinBufferSize(44100...*
Whichever one of these calls succeeds, I use that rate in my call to "*new
AudioRecord(..,sampleRate..)*"
I don't actually have one of these misbehaving devices, so my
experiments so far have been with the help of my customers.
-Robert Scott
Hopkins, MN
--
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/android-developers/c04a2d86-42bd-46dc-892e-4ef32b4b6759%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Audio recording problem - fake sample rate
I am calling AudioRecord.getMinBufferSize(44100,AudioFormat.CHANNEL_IN_MONO,AudioFormat.ENCODING_PCM_16BIT) and using the returned minAudioRecordBufSize in new AudioRecord(MediaRecorder.AudioSource.MIC, 44100,AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, minAudioRecordBufSize); Is that sizing the buffers correctly? Thanks for the offer for the enumeration app, but I do not have a failing device at my disposal. Only a few devices are failing, and they are all owned by my customers. I can't ask too much of them in the way of debugging help. On Friday, January 15, 2016 at 1:34:15 AM UTC-6, Julian Bunn wrote: > > Make sure you are sizing the buffers correctly i.e. respecting the minimum > recording buffer size (in bytes) required. If you don't then I believe the > system will drop you down to 8kHz sample rate, which is what you are seeing > (I think?). > > > On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott wrote: >> >> I first call *AudioRecord.getMinBufferSize(22050...* If this returns an >> error (<1) then I call *AudioRecord.getMinBufferSize(44100...* >> Whichever one of these calls succeeds, I use that rate in my call to "*new >> AudioRecord(..,sampleRate..)*" >> >> I don't actually have one of these misbehaving devices, so my experiments >> so far have been with the help of my customers. >> >> -Robert Scott >> Hopkins, MN >> >> -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/b8184f0f-de72-457f-98c9-bc63d98343d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Microphone sampled at 8000 Hz on LG G3 phone
I got a report from a customer of my audio analysis app saying that the frequency spectrum graph we show has a mirror image of peaks about 4000 Hz (the Nyquist frequency for 8000 samples per second). Our app requests 22050 samples per second, and is getting 22050 samples per second. But apparently the system is up-sampling the microphone audio to be able to deliver what we ask for. The fact that the original sampling was done at 8000 Hz is not "fixed" by up-sampling. I saw this same thing in the very early days of Android on some cheap devices. But I didn't think anybody was still doing this sort of thing today. The LG G3 is not that old. Can anyone else confirm this behavior on the LG G3? Or have you seen such things recently? -- 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 --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Must reboot Lollipop after write to external memory
This is a new problem with Lollipop only. My app writes to external memory by building a file path name from: Environment.getExternalStorageDirectory().getAbsolutePath() But when I plug the USB into a desktop computer, the new file does not show up in Explorer. If I reboot the Lollipop Android tablet and try it again, the file now shows up in Explorer on the desktop computer. Furthermore, if the file already existed, then the version of the file that Explorer sees is the new updated version, just as it should be. Brand new files do not show up until a reboot of Android. Also, this was not a problem with KitKat. New files written by my app showed up immediately on the USB-connected computer. Is there some way, in my app, to force new files to appear immediately to the outside world? I am writing to the root of the external memory. This is a side-loaded app, not a Market app, if that makes any difference. It has been working perfectly for 3 years, until this problem with Lollipop. -Robert Scott Hopkins, MN -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Is runOnUiThread() ever 'safe' to call? If not why is it not deprecated?
Google is still promoting runOnUiThread in their sample Bluetooth Low
Energy device scan callback code:
private BluetoothAdapter.LeScanCallback mLeScanCallback =
new BluetoothAdapter.LeScanCallback() {
@Override
public void onLeScan(final BluetoothDevice device, int rssi,
byte[] scanRecord) {
runOnUiThread(new Runnable() {
@Override
public void run() {
mLeDeviceListAdapter.addDevice(device);
mLeDeviceListAdapter.notifyDataSetChanged();
}
});
}
};
-Robert Scott
Hopkins, MN
On Tuesday, June 9, 2015 at 12:39:13 PM UTC-6, Sam Duke wrote:
Due to the nature of config changes, the runnable submitted to
runOnUiThread may be executed after an activity has been destroyed (i.e. on
a stale activity). Therefore this API can cause all sorts of subtle bugs
with config changes and events never reaching the UI. I can't think of a
single case where it would be safe to use this. You should already have hit
the main thread by the time you are doing anything inside the runnable... I
think all it does is encourage poor patterns...
Given this, is it not time to deprecate this API?
--
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
---
You received this message because you are subscribed to the Google Groups
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[android-developers] Why different icon sizes?
I tried using a clearly incorrect icon size for a launcher icon (386 x 386), and the icon was automatically down-sized on my Galaxy Tab 4 to look the same as all the other app icons. So I wonder why we need to provide 5 different launch icon sizes? Is this resizing behavior one that I can count on? (By the way, I am only making side-loaded apps, so Google Play Store requirements are not an issue for me.) Robert Scott Hopkins, MN -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Interfacing an android device (host mode) directly with a microcontroller via usb
The simplest way to do that is to use a USB-to-serial converter and program your Android app to talk to the converter module using the USB SPP protocol. Then your micro controller program is simply talking over its UART. If you want to stay with USB all the way, then you will have to use a micro with a USB interface and implement the SPP protocol on that micro. This is not easy. USB is not a generic communication protocol like serial async. The Android system needs to have a driver to the specific USB protocol you want to use. Besides SPP, you could use the HID protocol and make your micro controller emulate a keyboard. Then your application would have to be structured so as to use a keyboard interface, which is quite restrictive on your application. Overall, I would say the converter module is the easiest approach. Robert Scott Hopkins, MN -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Ideal Bluetooth Service
I have implemented Bluetooth in several of my projects where the Android device is the user interface to a custom device with a Bluetooth module using the SPP profile (serial port replacement). But I want to clean up my code and make it more robust. Since I expect to be doing more of these projects in the future, I would like to modularize my Bluetooth Service so that it does not depend on the client class code in any way. I've got a Service working, complete with a thread to read Bluetooth data and deliver each packet of data to the client (which is generally a local Activity). But my method of delivering data back to the client is by means of a handler in that client. That means my Bluetooth Service code needs to depend on the client code. I want to get away from this method for that reason. The Binder interface when the Activity binds to the client is fine for the client calling the Service. But I can't find a similar lightweight method for the Service to communicate with the client (such as when it receives a packet of Bluetooth data). My Bluetooth thread that reads the data can post to a handler to get on the UI thread. But then I am stuck. If I could create another Binder in the opposite direction, that would be great. The client would just create the instance of Binder and my Service could call a method in that Binder without have to know anything more about the client class. But how can I pass a Binder created in the client to the Service? I don't think I can do it in the Intent passed in with bindService, because a Binder is not Parcelable, so it cannot be added to the Intent with putExtra. I know that Messenger and AIDL exist, but I prefer the lightweight methods for performance reasons. Is there something I am missing that seems to make this job so hard? -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Ideal Bluetooth Service
After I posted this question I found a reference to using Messenger that seemed to indicate it was about as lightweight as Binder, being just a wrapper for it. And I have a nice example of using Messenger for 2-way communication here on Stack Overflow http://stackoverflow.com/questions/4300291/example-communication-between-activity-and-service-using-messaging. So I think that is what I will settle on. -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: AudioRecord.read returns duplicate data
(SOLVED!) Here's what I found out. My construction of the AudioRecord object was like this: new AudioRecord(MediaRecorder.AudioSource.MIC, 22050,AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, myBufSize); where myBufSize was set to a very large 16384. And this caused the repetition of data every 8192 samples. But when I changed myBufSize to 1792 (the value returned by AudioRecord.getMinBufferSize), then all the duplication ceased, and every sample was delivered once, and all is well. I am reading data at 1024 samples per read. I still don't know why data duplication happens for very large settings of myBufSize in the constructor, but it does. Tomorrow I will investigate intermediate values of myBufSize to see at what point the problem begins. On Friday, October 10, 2014 9:45:32 PM UTC-6, RLScott wrote: In my musical instrument tuner app I stream audio data to my analysis code with an AudioRecord.read() method which runs in a separate thread to decouple it from the UI. The AudioRecord was set up with a sample rate of 22050 and a 16384 samples. I read the data in chunks of 1024 samples at a time. This all works perfectly on every Android device I have checked - except for the Moto G. On that device I have been able to verify that the data is being corrupted by AudioRecord.read() returning some data that was returned earlier. 8192 samples earlier, to be exact. This causes a phase jump in the audio data, and therefore an unstable tuning indication. The data is being read into a direct buffer. Does anyone know why the Moto G is doing this? -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] AudioRecord.read returns duplicate data
In my musical instrument tuner app I stream audio data to my analysis code with an AudioRecord.read() method which runs in a separate thread to decouple it from the UI. The AudioRecord was set up with a sample rate of 22050 and a 16384 samples. I read the data in chunks of 1024 samples at a time. This all works perfectly on every Android device I have checked - except for the Moto G. On that device I have been able to verify that the data is being corrupted by AudioRecord.read() returning some data that was returned earlier. 8192 samples earlier, to be exact. This causes a phase jump in the audio data, and therefore an unstable tuning indication. The data is being read into a direct buffer. Does anyone know why the Moto G is doing this? -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Pressing Menu button with ActionBar shows an dark overlay
New information: I just realized that I am unable to demonstrate this behavior on anything other than the Eclipse simulator. That's because I don't have any real Android devices that are both Android 3.0 or above and have a separate hardware menu button. The more modern ways of getting at the menu function (long press the app switcher button, or tap ActionBar overflow icon) all hide themselves when there is no menu to display. But I constructed an Android virtual device in Eclipse by specifying both Android 3.2 and the hardware menu button. So maybe this is a non-problem. I don't have to worry about Android 3.0 because my app requires 3.0 for other reasons. As long as there are no Android devices with both 3.0 and above and a hardware menu key, I think I am OK. -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Determining ActionBar overflow or not
I have several ActionBar items that each display a popup menu. When these items are visible in the ActionBar there is no problem. The user taps on the item in the ActionBar and immediately the appropriate popup menu appears. But sometimes, on some devices, one or more of my ActionBar items may be in the overflow. When that happens, the user taps the overflow button and an overflow menu is presented from which the user can choose which popup menu he would like to see. Then he sees the popup menu, and that is also working OK, but it takes one extra tap. I would like to streamline the user interaction just a little. On the occasion that there is only one of my ActionBar items in the overflow (if that is even possible - I don't know), I would like to skip the intermediate choice and go straight to the one popup menu whose button was in the overflow. Is that possible? Or is it even necessary? Can there be only one item in the ActionBar overflow? So far I have simulated this situation by temporarily setting android:showAsAction=never for one of the ActionBar items. In production I will use always, but I don't know if there are situations where the Android system will not honor my always request. -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Pressing Menu button with ActionBar shows an dark overlay
I am migrating from an old-style Menu button menu to the ActionBar in an
app that targets Android 3.0 and above. My ActionBar buttons are working
fine. But on devices that still have a hardware Menu button, the Menu
button causes the whole screen to be overlaid with a semi-transparent dark
screen, as if it were a very large empty menu. If any of my ActionBar
items are in the overflow menu (not displayed), then pressing the Menu
button brings up those overflowed items, which is fine. But if none of my
ActionBar items are in the overflow (they are all displayed in the
ActionBar), I want the Menu button to do nothing, but I can't get that to
happen. On devices without a Menu button, everything is fine because the
overflow icon is suppressed when there is nothing in the ActionBar overflow.
My ActionBar implementation is very standard:
@Override
public boolean onCreateOptionsMenu(Menu menu) {
MenuInflater inflater = getMenuInflater();
inflater.inflate(R.menu.activity_main_actions, menu);
return super.onCreateOptionsMenu(menu);
}
where menu/activity_main_actions.xml lists two items with
showAsAction=ifRoom. If I change one of them to never, the Menu button
shows me that item in a small menu, as it should. But if both things are
shown in the ActionBar, the Menu button shows the dark overlay that goes
away when you press the Back button. Is there any way I can prevent this
empty menu dark overlay?
--
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
---
You received this message because you are subscribed to the Google Groups
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Positioning Buttons side by side in Linear Layout (one button multi-lined)
By different vertical positions I mean that the two buttons are side by side, but one is positioned slightly higher on the screen, as shown in the attached two-buttons.png. -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Positioning Buttons side by side in Linear Layout (one button multi-lined)
On Thursday, June 26, 2014 9:08:45 AM UTC-6, TreKing wrote: I see. Try changing the button heights to match parent and the containing layout to whatever height you want it. No, that didn't help either. The attached two-buttons.png is what happens with this XML: LinearLayout android:layout_width=match_parent android:layout_height=60sp Button android:id=@+id/cancelButton android:layout_width=0dp android:layout_height=60sp android:layout_marginLeft=6sp android:layout_marginRight=6sp android:layout_weight=0.5 android:background=# android:onClick=onClickCancel android:text=Cancel the Calibration android:textColor=#ff00 android:textSize=18sp /Button Button android:id=@+id/beginButton android:layout_width=0dp android:layout_height=60sp android:layout_marginLeft=6sp android:layout_marginRight=6sp android:layout_weight=0.5 android:background=#ffaaffaa android:onClick=onClickBegin android:text=Begin android:textColor=#ff00 android:textSize=18sp /Button /LinearLayout But if I just change Begin to Begin the Calibration so that it takes up two lines just like the other button, then everything is OK, as shown by the attached two-buttons-OK.png. -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Positioning Buttons side by side in Linear Layout (one button multi-lined)
On Thursday, June 26, 2014 9:08:45 AM UTC-6, TreKing wrote: I see. Try changing the button heights to match parent and the containing layout to whatever height you want it. That fixed it! Although I don't know why it didn't work before. Thanks. -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Positioning Buttons side by side in Linear Layout (one button multi-lined)
Two buttons are to be placed side by side in a horizonally-oriented LinearLayout whose width is match_parent. To make the buttons share the width equally I have assigned each Button the layout_weight of 0.5. Everything looks good if both buttons have a single line of text, or if both buttons have two lines of text. But when one button has 2 lines and the other button has 1 line, the two buttons appear at slightly different vertical positions. They both have a fixed height (60sp) to allow for 1 or 2 lines of text. How can I make these buttons look symmetrical? Here is the xml: LinearLayout android:layout_width=match_parent android:layout_height=wrap_content Button android:layout_height=60sp android:layout_weight=0.5 android:text=Cancel the Calibration android:textSize=18sp /Button Button android:layout_height=60sp android:layout_weight=0.5 android:text=Accept android:textSize=18sp /Button /LinearLayout This is being rendered on a 320x480 portrait screen under Android 3.1. Why don't they appear at the same vertical position on the screen? -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Positioning Buttons side by side in Linear Layout (one button multi-lined)
dp instead of sp made no difference. The two buttons still appear at different vertical positions when only one of them has text that takes up two lines. On Wednesday, June 25, 2014 9:54:03 AM UTC-6, Tushar Lal wrote: Instead of sp try dp... On Jun 25, 2014 7:06 PM, 'RLScott' via Android Developers android-d...@googlegroups.com javascript: wrote: Two buttons are to be placed side by side in a horizonally-oriented LinearLayout whose width is match_parent. To make the buttons share the width equally I have assigned each Button the layout_weight of 0.5. Everything looks good if both buttons have a single line of text, or if both buttons have two lines of text. But when one button has 2 lines and the other button has 1 line, the two buttons appear at slightly different vertical positions. They both have a fixed height (60sp) to allow for 1 or 2 lines of text. How can I make these buttons look symmetrical? Here is the xml: LinearLayout android:layout_width=match_parent android:layout_height=wrap_content Button android:layout_height=60sp android:layout_weight=0.5 android:text=Cancel the Calibration android:textSize=18sp /Button Button android:layout_height=60sp android:layout_weight=0.5 android:text=Accept android:textSize=18sp /Button /LinearLayout This is being rendered on a 320x480 portrait screen under Android 3.1. Why don't they appear at the same vertical position on the screen? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@googlegroups.com javascript: To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Recursive Activities - not possible?
I need to implement a File Explorer as an activity within my app. One of the functions of such an activity is the ability to recursively navigate up and down the directory tree. I was planning on doing that by having the current instance of the File Explorer start another instance of the File Explorer when then the user taps on a directory entry. I was going to have each instance storing its place in the tree (as a path name) so that I could pop this stack all the way to the beginning. But then I remembered the Activity life cycle, and the fact that Android can destroy any activity that is not visible. So that would trash my stack, if the stack was stored as instance data for each instance of the File Explorer. Do I have that right? And if so, what is a preferable way to manage a stack of nested instances of a File Explorer activity? -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Recursive Activities - not possible?
I should have mentioned that the file structure in question Dropbox, and
the access methods are the Dropbox Sync API, but I think your suggestion is
a good one, once I figure out the Dropbox equivalents for the native
Android file access methods. I will do that instead of spawn new instances
of the Activity.
On Wednesday, June 18, 2014 1:32:58 PM UTC-6, Kostya Vasilyev wrote:
How about:
onBackPressed() {
File newDirectory = mCurrentDirectory.getParentFile();
if (newDirectory != null) {
mCurrentDirectory = newDirectory;
reloadFileList(mCurrentDirectory);
}
}
-- K
--
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
---
You received this message because you are subscribed to the Google Groups
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
