Let's look at the problem
- First adjust the volume of a call, after the ring volume and alarm volume will be linked phenomenon
- Adjust either volume with the volume bar springback
- Open High volume, quick slide up and down the page, adjust the volume bar will jump to the last position, then back to the normal position (provided that the volume to be adjusted and to quickly slide page)
Let's look at the program
The first question finally say, start with the second question to start. Some problems, by repeating the recurring problem, you can find some laws, the laws from which I can safely guess locate problems or to bypass certain bug.
Question two:
This volume rebound, through repeated tests found that every rebound position is the position of the previous adjustment, and the volume size is the size of the bounce position, which shows that the value of the database is not set up, then our bold figure out why will be the last value, there may be time assignment problem, go see the location where the logic verification under speculation. alps / frameworks / base / core / java / android / preference / SeekBarVolumizer.java code in this open look.
postSetVolume (int progress) debugging found that the problem really is in this progress, the set is mLastAudibleStreamVolume this thing, but the fact is that this thing is not very timely change, the logic is to drag the volume slider after this method is called to update the database. Therefore, the solution to the problem bill is onProgressChanged time, engage in a member variable record current location, then leave at the time of the finger to change the database onStopTrackingTouch.
Question three:
According to the above two problems idea, we first analyze the problem Three phenomena, and from time to set up home for the first time into the volume does not exhibit this problem, you need to adjust the volume once after entering, then swipe the page to note here next, the volume of the bottom part of the senior cancel folded to reproduce the problem, and several tests found that the position of the slider flashing, also the location of the previous adjustment, here we have three pieces of information:
- Enter the page initialization of no such phenomenon
- Article conditioned not come in when no such phenomenon, after the position adjustment is flashing position
- Volume bar has been no such phenomenon in the field of view of time
Well, derived from the information in question is definitely a problem with the progress bar progress and problem areas in time for the volume bar to reload, then we'll see a problem with the code alps / vendor / mediatek / proprietary / packages /apps/MtkSettings/src/com/android/settings/widget/SeekBarPreference.java Sure enough, when fast sliding volume appeared to re-away method onBindViewHolder (PreferenceViewHolder view) of
@Override
public void onBindViewHolder(PreferenceViewHolder view) {
super.onBindViewHolder(view);
view.itemView.setOnKeyListener(this);
mSeekBar = (SeekBar) view.findViewById(
com.android.internal.R.id.seekbar);
mSeekBar.setOnSeekBarChangeListener(this);
mSeekBar.setMax(mMax);
mSeekBar.setMin(mMin);
// 添加
Log.d("HZH", "onBindViewHolder: " + mCount);
boolean useSeekProgress = mCount > 0 && this instanceof VolumeSeekBarPreference;
mSeekBar.setProgress(useSeekProgress ? mSeekBar.getProgress() : mProgress);
mCount++;
// 添加结束
final CharSequence title = getTitle();
mSeekBar.setEnabled(isEnabled());
.......
}mSeekBar.setProgress time, mProgress progress is the result of the previous article, it is concluded that the problem here, as to why use mCount> 0 determine it, it is because the new volume bar to see when to go twice onBindViewHolder the way we want to go in a second time before they can change, with the addition, instanceof VolumeSeekBarPreference in order to avoid the effects of setting seekbar other locations, such as accessibility of seekbar speech to text is also used for this, not to judge it will lead to, the volume bar can not be reset. Question three or more to resolve.
Question one:
Look at the last question, this bug is really strange, really, the code is really metaphysics, Google's big brother is also a lot of bug, and hidden very deeply. On the surface really no clue, only "FML, this special What What?!" Surfaced in my mind, but think about it later, or have a point of direction, time to adjust the ring I did not touch the alarm clock seekbar ah, can not distinguish that are hand touched it?
With only clue to see the code, SeekBarVolumizer.java and a problem with is the same thing, it was found that a place can be distinguished, onProgressChanged when you can distinguish, then tried to change a law in accordance with the following comment, really nailed it.
public class SeekBarVolumizer implements OnSeekBarChangeListener, Handler.Callback {
private static final String TAG = "SeekBarVolumizer";
...................................
private boolean mFromTouch;
private int mProgress;
......................
protected void updateSeekBar() {
final boolean zenMuted = isZenMuted();
mSeekBar.setEnabled(!zenMuted);
// Modify
if((mLastProgress == -1) || (mLastAudibleStreamVolume == mLastProgress)){
//Modify end
if (zenMuted) {
mSeekBar.setProgress(mLastAudibleStreamVolume, true);
} else if (mNotificationOrRing && mRingerMode == AudioManager.RINGER_MODE_VIBRATE) {
mSeekBar.setProgress(0, true);
} else if (mMuted) {
mSeekBar.setProgress(0, true);
} else {
mSeekBar.setProgress(mLastProgress > -1 ? mLastProgress : mOriginalStreamVolume, true);
}
}
}
@Override
public boolean handleMessage(Message msg) {
switch (msg.what) {
case MSG_SET_STREAM_VOLUME:
// 删除
//if (mMuted && mLastProgress > 0) {
// mAudioManager.adjustStreamVolume(mStreamType, AudioManager.ADJUST_UNMUTE, 0);
//} else if (!mMuted && mLastProgress == 0) {
// mAudioManager.adjustStreamVolume(mStreamType, AudioManager.ADJUST_MUTE, 0);
//}
// 删除结束
mAudioManager.setStreamVolume(mStreamType, mLastProgress,
AudioManager.FLAG_SHOW_UI_WARNINGS);
break;
.......
}
public void onProgressChanged(SeekBar seekBar, int progress, boolean fromTouch) {
// 添加
mProgress = progress;
mFromTouch = fromTouch;
//添加
}
//添加
private void startChangeProgress(SeekBar seekBar){
Log.d(TAG,"mProgress: "+mProgress);
if (mFromTouch) {
postSetVolume(mProgress);
}
if (mCallback != null) {
mCallback.onProgressChanged(seekBar, mProgress, mFromTouch);
}
}
//添加
............
public void onStopTrackingTouch(SeekBar seekBar) {
// 添加
startChangeProgress(seekBar);
// 添加结束
postStartSample();
}
...........
}This, three problems are solved, I found this article code is actually C to 5 coins , completely free in my place , but if you have the opportunity to help, hoping to leave a praise, if there is a problem or better solution, please let me know.
