[android-developers] Re: Nexus 4 windows 8.1 can't install google adb driver.
Well I solved this one on my own, and here's the answer for anyone who wants to know: Apparently some USB 3.0 ports don't recognize the device quite properly unless it's already got a driver installed via a USB 2.0 port. In other words, it doesn't recognize the adb portion of the device, only the mtp portion. If you first install it with the USB 2.0 port, then it works fine in the 3.0 ports as well! On Monday, April 21, 2014 11:14:44 PM UTC-7, Casvah wrote: > > When trying to install the driver for my n4 in MTP mode, windows reports > "The folder you specified doesn't contain a compatible software driver for > your device. If the folder contains a driver, make sure it is designed to > work with Windows for x64-based systems." > > The problem happens with revision 9 of the driver. I used to be able to > install in MTP mode without problem, but now windows won't let me. Is there > something accidentally missing from the driver file that I have to wait for > google to fix, or is there something I can do to make this work? > > I also tried Koush's universal adb driver. It installs fine, but I do not > see my device in the output of adb devices with this driver. > > It seems to work just fine and dandy if I put the device in PTP mode, but > that limits my ability to transfer files onto most parts of my device. > > What happened and how can I fix it? > -- 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: how to move non-movable apps to SD card
They're non-moveable for a reason. You would need to have a rooted phone with special functionality to move them to an sdcard. Even then, you can't move apps with widgets or apps that have services you want to keep running because if the card gets unmounted it'll crash them. On Saturday, April 19, 2014 7:11:15 AM UTC-7, Josphat Muchiri wrote: > > hello guys, i have a problem moving non-movable apps in my android phone > to SD card, pliz any help > -- 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] Nexus 4 windows 8.1 can't install google adb driver.
When trying to install the driver for my n4 in MTP mode, windows reports "The folder you specified doesn't contain a compatible software driver for your device. If the folder contains a driver, make sure it is designed to work with Windows for x64-based systems." The problem happens with revision 9 of the driver. I used to be able to install in MTP mode without problem, but now windows won't let me. Is there something accidentally missing from the driver file that I have to wait for google to fix, or is there something I can do to make this work? I also tried Koush's universal adb driver. It installs fine, but I do not see my device in the output of adb devices with this driver. It seems to work just fine and dandy if I put the device in PTP mode, but that limits my ability to transfer files onto most parts of my device. What happened and how can I fix it? -- 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] Preserving Compound Control View State Across Configuration Changes
I have a compound control containing an AutoCompleteTextView, a CheckBox,
and an ImageButton. The layout is inflated from xml. The control is added
added at runtime to a linearlayout when a user clicks an 'Add' button.
I need to preserve the values of the textview and the checkbox across
configuration changes, so I implement the following INSIDE the compound
control class.
@Override
protected Parcelable onSaveInstanceState() {
// Create a bundle to save our state in
Bundle b = new Bundle();
// Save the superclass' instanceState
b.putParcelable("instanceState", super.onSaveInstanceState());
// Save the AutoCompleteTextView
AutoCompleteTextView acTextView = (AutoCompleteTextView)
findViewById(R.id.houseEditFragmentProConView_autoCompleteTextView1);
b.putString("acTextView", acTextView.getText().toString());
// Save the CheckBox
CheckBox cb = (CheckBox)
findViewById(R.id.houseEditFragmentProConView_checkBox1);
b.putBoolean("cb", cb.isChecked());
// Return the saved state
return b;
}
@Override
protected void onRestoreInstanceState(Parcelable state) {
if (state instanceof Bundle) {
Bundle b = (Bundle) state;
AutoCompleteTextView acTextView = (AutoCompleteTextView)
findViewById(R.id.houseEditFragmentProConView_autoCompleteTextView1);
acTextView.setText(b.getString("acTextView"));
CheckBox cb = (CheckBox)
findViewById(R.id.houseEditFragmentProConView_checkBox1);
cb.setChecked(b.getBoolean("cb"));
super.onRestoreInstanceState(b.getParcelable("instanceState"));
return;
}
super.onRestoreInstanceState(state);
}
When I change the orientation of the screen, ALL of these controls are
lost. So I overrode the fragment's onSaveInstanceState method with a loop
to store all of the control.getid()'s in an ArrayList. Then in the
fragment's onViewCreated method, I loop through that arrayList (extracted
from the bundle), and create a control for each id in the arraylist, and
set that id on it before adding it to the containing view.
As I understand it, if you recreate a control and give it the same ID as a
control that was destroyed in an orientation change, Android will refill
the data it had. My problem is that even though all the controls show back
up and have data in them, they all have the SAME data as the LAST control
that was stored, instead of having their individual unique datas.
How can I fix this? Relevant portions from the fragment posted below:
@Override
public void onViewCreated(View view, Bundle savedInstanceState) {
super.onViewCreated(view, savedInstanceState);
LinearLayout prosConsView = (LinearLayout) getSherlockActivity()
.findViewById(R.id.houseEditFragment_linearLayout_Pros);
if (savedInstanceState == null) {
buttonAdd.performClick();
EditText editTextAddress = (EditText) getSherlockActivity()
.findViewById(R.id.houseEditFragment_editText_Address);
editTextAddress.requestFocus();
} else {
// TODO: Restore fragment from savedInstanceState in case of
// orientation
// change or if this gets killed
ArrayList recoveredProsConsIds = savedInstanceState
.getIntegerArrayList("prosConsIds");
Log.d(LocalApplication.DEBUG_TAG, "RECOVERED ARRAY: "
+ recoveredProsConsIds);
HouseEditFragmentProConView workingProConView;
for (Integer id : recoveredProsConsIds) {
workingProConView = new HouseEditFragmentProConView(
getSherlockActivity(), null);
workingProConView.setId(id);
Log.d(LocalApplication.DEBUG_TAG, "Restore: "
+ workingProConView.getId() + " " + workingProConView.getText().toString());
prosConsView.addView(workingProConView);
}
for (int i = 0; i < prosConsView.getChildCount(); i++) {
workingProConView = (HouseEditFragmentProConView) prosConsView
.getChildAt(i);
Log.d(LocalApplication.DEBUG_TAG,
"Check: " + workingProConView.getId() + " " +
workingProConView.getText().toString());
}
}
}
@Override
public void onSaveInstanceState(Bundle outState) {
// TODO Save the form in case of configuration change or if the user
// changes apps and this gets killed
// EditText address = (EditText)
//
getSherlockActivity().findViewById(R.id.houseEditFragment_editText_Address);
// outState.putString("address", address.getText().toString());
LinearLayout prosCons = (LinearLayout) getSherlockActivity()
.findViewById(R.id.houseEditFragment_linearLayout_Pros);
ArrayList storedProsConsIds = new ArrayList();
for (int i = 0; i < prosCons.getChildCount(); i++) {
HouseEditFragmentProConView current = (HouseEditFragmentProConView) prosCons
.getChildAt(i);
storedProsConsIds.add(current.getId());
Log.d(LocalApplication.DEBUG_TAG, "Save: " + current.getId() + " " +
current.getText().toString());
}
outState.putIntegerArrayList("prosConsIds", storedProsConsIds);
super.onSaveInstanceState(outState);
}
--
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
ht
Re: [android-developers] Fragment.onActivityResult is not called
OK! I solved my problem. Teaches me to code when tired. I was simply missing a .show() after my toast. :( On Thursday, April 26, 2012 6:21:03 PM UTC-5, Casvah wrote: > > Ok, I'll verify I have the current version of the compatibility library. > If it is fixed, what would cause my fragment's onActivityResult callback > method to never be called? > > On Thursday, April 26, 2012 4:42:41 AM UTC-5, Kostya Vasilyev wrote: >> >> The bug is in the compatibility library, not the platform, so no firmware >> updates are involved. >> >> The native platform implementation of this is different. >> >> It appears fixed in the current version of the compat library (v7?), I >> believe it has been for a long time. >> >> -- K >> >> 26 апреля 2012 г. 6:32 пользователь Zsolt Vasvari >> написал: >> >>> Oh, I see this is from 2011, not this March. Never mind -- the fix >>> should certainly be part of 3.2 and ICS. >>> >>> >>> On Thursday, April 26, 2012 10:09:38 AM UTC+8, Zsolt Vasvari wrote: >>>> >>>> I am sure it will be fixed in whatever the next version of Android is >>>> and if they back port the fix and the phones get updated (likelihood: >>>> 0.0001%). >>>> >>>> So unless you are targeting ONLY the non-yet public next version of the >>>> SDK, you might as well just not even assume this fix exists and code >>>> around >>>> it somehow. >>>> >>>> >>>> >>>> On Thursday, April 26, 2012 9:24:59 AM UTC+8, Casvah wrote: >>>>> >>>>> Has this issue been fixed? The bug report on the issue tracker says >>>>> it's closed, but there are new comments from people having this issue. I >>>>> am >>>>> also having this issue. I might be doing it wrong though, since I can't >>>>> get >>>>> it to work with any request code. >>>>> >>>>> On Thursday, March 10, 2011 12:15:12 PM UTC-6, Dianne Hackborn wrote: >>>>>> >>>>>> Whoops, yeah that is a bug. Thanks for finding it. I'll fix it in >>>>>> the next update. >>>>>> >>>>>> On Thu, Mar 10, 2011 at 1:55 AM, Pete Doyle wrote: >>>>>> >>>>>>> Ran into this issue tonight on my Droid (2.2). I think there's an >>>>>>> issue in FragmentActivity.**startActivityFromFragment(...)**. >>>>>>> >>>>>>> YMMV, but this seems to fix it for me: >>>>>>> https://github.com/petedoyle/**android-support-v4-googlemaps/** >>>>>>> commit/**06307de35a9de0a89ff52bb42a358b**a6740e542c<https://github.com/petedoyle/android-support-v4-googlemaps/commit/06307de35a9de0a89ff52bb42a358ba6740e542c> >>>>>>> >>>>>>> Basically there are two issues: >>>>>>> 1) "(fragment.mIndex+1)<<16" should be in parentheses since + has >>>>>>> precedence over << in Java >>>>>>> 2) requestCode*0x should be requestCode&0x. (I think the >>>>>>> goal is to strip all but the first 16 bits of the request code). >>>>>>> >>>>>>> To understand the fix, assume you have a fragment index of 0 and a >>>>>>> requestCode of 1. >>>>>>> >>>>>>> With the current code: >>>>>>> (fragment.mIndex+1)<<16 + (**requestCode*0x) >>>>>>> = (0+1)<<16 + (1*0x) >>>>>>> = (1)<< (16 + 0x) // since + has precedence over << >>>>>>> = 1<<65551 >>>>>>> = 32768 // according to my debugger >>>>>>> = 1000 // fragment index is lost, request code >>>>>>> changes from 1 to 32768 >>>>>>> >>>>>>> With this change: >>>>>>> ((fragment.mIndex+1)<<16) + (**requestCode&0x) >>>>>>> = ((0+1)<<16) + (1&0x) >>>>>>> = (1<<16) + 1 >>>>>>> = 65536 + 1 >>>>>>> = 65537 >>>>>>> = 1 0001 >>>>>>> >>>>>>> Thanks, >>>>>>> Pete >>>>>>> >>>>>>> On Wed, Mar 9, 2011 at 9:20 AM, Dianne Hackborn >>>&
Re: [android-developers] Fragment.onActivityResult is not called
Ok, I'll verify I have the current version of the compatibility library. If it is fixed, what would cause my fragment's onActivityResult callback method to never be called? On Thursday, April 26, 2012 4:42:41 AM UTC-5, Kostya Vasilyev wrote: > > The bug is in the compatibility library, not the platform, so no firmware > updates are involved. > > The native platform implementation of this is different. > > It appears fixed in the current version of the compat library (v7?), I > believe it has been for a long time. > > -- K > > 26 апреля 2012 г. 6:32 пользователь Zsolt Vasvari написал: > >> Oh, I see this is from 2011, not this March. Never mind -- the fix >> should certainly be part of 3.2 and ICS. >> >> >> On Thursday, April 26, 2012 10:09:38 AM UTC+8, Zsolt Vasvari wrote: >>> >>> I am sure it will be fixed in whatever the next version of Android is >>> and if they back port the fix and the phones get updated (likelihood: >>> 0.0001%). >>> >>> So unless you are targeting ONLY the non-yet public next version of the >>> SDK, you might as well just not even assume this fix exists and code around >>> it somehow. >>> >>> >>> >>> On Thursday, April 26, 2012 9:24:59 AM UTC+8, Casvah wrote: >>>> >>>> Has this issue been fixed? The bug report on the issue tracker says >>>> it's closed, but there are new comments from people having this issue. I >>>> am >>>> also having this issue. I might be doing it wrong though, since I can't >>>> get >>>> it to work with any request code. >>>> >>>> On Thursday, March 10, 2011 12:15:12 PM UTC-6, Dianne Hackborn wrote: >>>>> >>>>> Whoops, yeah that is a bug. Thanks for finding it. I'll fix it in >>>>> the next update. >>>>> >>>>> On Thu, Mar 10, 2011 at 1:55 AM, Pete Doyle wrote: >>>>> >>>>>> Ran into this issue tonight on my Droid (2.2). I think there's an >>>>>> issue in FragmentActivity.**startActivityFromFragment(...)**. >>>>>> >>>>>> YMMV, but this seems to fix it for me: >>>>>> https://github.com/petedoyle/**android-support-v4-googlemaps/** >>>>>> commit/**06307de35a9de0a89ff52bb42a358b**a6740e542c<https://github.com/petedoyle/android-support-v4-googlemaps/commit/06307de35a9de0a89ff52bb42a358ba6740e542c> >>>>>> >>>>>> Basically there are two issues: >>>>>> 1) "(fragment.mIndex+1)<<16" should be in parentheses since + has >>>>>> precedence over << in Java >>>>>> 2) requestCode*0x should be requestCode&0x. (I think the >>>>>> goal is to strip all but the first 16 bits of the request code). >>>>>> >>>>>> To understand the fix, assume you have a fragment index of 0 and a >>>>>> requestCode of 1. >>>>>> >>>>>> With the current code: >>>>>> (fragment.mIndex+1)<<16 + (**requestCode*0x) >>>>>> = (0+1)<<16 + (1*0x) >>>>>> = (1)<< (16 + 0x) // since + has precedence over << >>>>>> = 1<<65551 >>>>>> = 32768 // according to my debugger >>>>>> = 1000 // fragment index is lost, request code >>>>>> changes from 1 to 32768 >>>>>> >>>>>> With this change: >>>>>> ((fragment.mIndex+1)<<16) + (**requestCode&0x) >>>>>> = ((0+1)<<16) + (1&0x) >>>>>> = (1<<16) + 1 >>>>>> = 65536 + 1 >>>>>> = 65537 >>>>>> = 1 0001 >>>>>> >>>>>> Thanks, >>>>>> Pete >>>>>> >>>>>> On Wed, Mar 9, 2011 at 9:20 AM, Dianne Hackborn >>>>>> wrote: >>>>>> >>>>>>> Does the API demo for this work wherever you are running it? I have >>>>>>> tested it on 3.0, 2.3, and 1.6, and it works in those places, not would >>>>>>> I >>>>>>> expect it to have any trouble elsewhere. (How this works is very >>>>>>> simple, >>>>>>> it just masks out the top X bits of the request code to determine which >>>>>>> fragment
Re: [android-developers] Fragment.onActivityResult is not called
Has this issue been fixed? The bug report on the issue tracker says it's
closed, but there are new comments from people having this issue. I am also
having this issue. I might be doing it wrong though, since I can't get it
to work with any request code.
On Thursday, March 10, 2011 12:15:12 PM UTC-6, Dianne Hackborn wrote:
>
> Whoops, yeah that is a bug. Thanks for finding it. I'll fix it in the
> next update.
>
> On Thu, Mar 10, 2011 at 1:55 AM, Pete Doyle wrote:
>
>> Ran into this issue tonight on my Droid (2.2). I think there's an issue
>> in FragmentActivity.startActivityFromFragment(...).
>>
>> YMMV, but this seems to fix it for me:
>>
>> https://github.com/petedoyle/android-support-v4-googlemaps/commit/06307de35a9de0a89ff52bb42a358ba6740e542c
>>
>> Basically there are two issues:
>> 1) "(fragment.mIndex+1)<<16" should be in parentheses since + has
>> precedence over << in Java
>> 2) requestCode*0x should be requestCode&0x. (I think the goal
>> is to strip all but the first 16 bits of the request code).
>>
>> To understand the fix, assume you have a fragment index of 0 and a
>> requestCode of 1.
>>
>> With the current code:
>> (fragment.mIndex+1)<<16 + (requestCode*0x)
>> = (0+1)<<16 + (1*0x)
>> = (1)<< (16 + 0x) // since + has precedence over <<
>> = 1<<65551
>> = 32768 // according to my debugger
>> = 1000 // fragment index is lost, request code changes
>> from 1 to 32768
>>
>> With this change:
>> ((fragment.mIndex+1)<<16) + (requestCode&0x)
>> = ((0+1)<<16) + (1&0x)
>> = (1<<16) + 1
>> = 65536 + 1
>> = 65537
>> = 1 0001
>>
>> Thanks,
>> Pete
>>
>> On Wed, Mar 9, 2011 at 9:20 AM, Dianne Hackborn wrote:
>>
>>> Does the API demo for this work wherever you are running it? I have
>>> tested it on 3.0, 2.3, and 1.6, and it works in those places, not would I
>>> expect it to have any trouble elsewhere. (How this works is very simple,
>>> it just masks out the top X bits of the request code to determine which
>>> fragment to deliver the result to.)
>>>
>>> Also of course if you are overriding
>>> FragmentActivity.onActivityResult(), you *do* need to be sure to call the
>>> inherited version. The behavior here is slightly different than the HC
>>> implementation; the activity method will always be called first.
>>>
>>>
>>> On Wed, Mar 9, 2011 at 8:14 AM, drasticp wrote:
>>>
I have an application that targets 2.1. I'm using the Android
Compatibility Package to migrate the code in my Activities to
Fragments. I had an Activity which was launching a contact picker as
follows:
Intent contactPickerIntent = new Intent(Intent.ACTION_PICK,
Contacts.CONTENT_URI);
startActivityForResult(contactPickerIntent, CONTACT_PICKER_RESULT);
The result was appropriately handled in the onActivityResult for the
Activity:
@Override
public void onActivityResult(int requestCode, int resultCode, Intent
data) {
if (resultCode != Activity.RESULT_OK) return;
switch (requestCode) {
case CONTACT_PICKER_RESULT:
handleResult(data);
break;
}
}
Now, I've migrated both the startActivityForResult call and the
onActivityResult into a Fragment. I have also extended
FragmentActivity in the hosting Activity.
The contact picker still launches correctly, but onActivityResult in
the fragment is never called. If I override onActivityResult in the
FragmentActivity, it *IS* called. However, I don't want to handle the
result there because it breaks the encapsulation philosophy of the new
fragments.
Shouldn't onActivityResult in the fragment be called? Am I missing
something? Thanks for your assistance!
--
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
>>>
>>>
>>>
>>> --
>>> Dianne Hackborn
>>> Android framework engineer
>>> hack...@android.com
>>>
>>> Note: please don't send private questions to me, as I don't have time to
>>> provide private support, and so won't reply to such e-mails. All such
>>> questions should be posted on public forums, where I and others can see and
>>> answer them.
>>>
>>> --
>>> 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
>
