You can't remove that option from the system settings interface. However, if you don't want cached data (files) to be deleted, don't store them in the cache. I'm assuming that you're working on an app of your own so that you have control over where your app data is being stored. Use of the cache doesn't happen arbitrarily... it's something that the app developer must implement. When all else fails reading the docs is worth a try. It's no harder than reading anything somebody may post on this forum!

There are one or two options for the basic communication mechanism between PC and target Android device, for example adb commands (via USB) would allow you to send Intents (android constructs, which if you don't know what they are you need to start with basic Android training before trying to proceed). However, Intents - when used in this way - provide no mechanism to return data BACK to the PC, so your captured images could not be returned. The most viable solution that I can envisage would use a socket interface, also running over USB. This would give you a fully bi-direction transport mechanism. I have implemented such a system and therefore know with certainty that it works. As the previous poster said it's quite a big task, but I'd say not huge providing you know what you're doing. Good luck!

Sorry Richard, no you're right! Intended for the original questioner - my mistake.

Ahmed, an Android application has an "Internal" data area - that is, an area within the Android file system where data used by that application alone resides. An app's sqlite DB lives in this area. You say that you want the DB to exist in the "root" area. In that case you're talking about "External" storage. It's called external because it is outside the app's assigned part of the file system. Most applications, that aren't part of the system, do NOT access External storage, and to do so an app requires special permissions that are not granted by default. Can you explain more about what problem you're trying to solve by wanting to put your DB in External storage? There may be a more conventional and easier way to achieve your aims.

There are one or two options for the basic communication mechanism between PC and target Android device, for example adb commands (via USB) would allow you to send Intents (android constructs, which if you don't know what they are you need to start with basic Android training before trying to proceed). However, Intents - when used in this way - provide no mechanism to return data BACK to the PC, so your captured images could not be returned. The most viable solution that I can envisage would use a socket interface, also running over USB. This would give you a fully bi-direction transport mechanism. I have implemented such a system and therefore know with certainty that it works. As the previous poster said it's quite a big task, but I'd say not huge providing you know what you're doing. Good luck!

I see two equally meaningless posts about "a priori" and "bayes". It seems that an assignment in the statistics / applied maths course has just been given and what does everybody do? Look through their course notes, refer to a text book or do some searching on Google, nope... ask Code Project!

What problem are you having (other than needing all of this code to exist)?

By "finer granularity" I meant only that you could build more frequently. For example if currently you build at (say) midnight each day after everybody has finished work, then if Module "X" was changed 3 times and now fails to compile you've got to figure out which change caused it to fail. If, however, you'd done several builds during the day (e.g. every 2 hours) then you have more chance of discovering a broken build for which only one checkin has been done. Taking this to an extreme you end up with CI = Continuous Integration in which typically there'll be a gate on the checkin process with some mandatory regression tests needing to be passed before checkin can be done. There are lots of ways to implement this in practice: you could allow checkin but advance a stable label only as each checkin is built and validated. In the ideal world CI should ensure that your code always builds. However this is a big topic which is why I suggested only a small change to your existing process rather than a fundamental change of strategy. Do you know Jenkins? If not, it's worth reading about, including [Jenkins CI](Continuous integration with Jenkins - Tutorial).

It seems to me that you could tackle this in one of two ways: (1) Finer granularity on your build process. Somebody else already suggested a full-blown CI solution, but you could (I suppose) build say 4 times per day, which would dice-up the problem and presumably help; (2) Semi-automate the debug process by correlating changed modules with locations where errors are arising. Option 1 requires that you can get those merges done more often and turn the build handle. Option 2 strikes me as a good thing to do anyway, but whether it adds much value will obviously depend on how "orthogonal" the changes are that people are making to the code: if many are making changes in the same few files then it's not really going to work.

I suggest that you add logging to your application using the default android log utility. This will make your investigation much easier. Using a debugger - as somebody else suggested - is a very valid approach, but where you are looking at real-time effects (which may or may not be relevant) there's no substitute for logging. You can do this as follows: Add this import to your MainActivity and Filter classes:

import android.util.Log;

Then add this static variable as a class variable to each:

private static final String TAG = "Himanshu";

Now add some logging like this:

while ((read = in.read(buff)) > 0) {
Log.i(TAG, "Raw audio: " + read); // *** Nick's suggested log point. ***
out.write(buff, 0, read);
}
out.flush();
byte[] audioBytes = out.toByteArray();
final FloatBuffer fb = ByteBuffer.wrap(audioBytes).asFloatBuffer();
final float[] dst = new float[fb.capacity()];
fb.get(dst);

Filter filter = new Filter(15000,44100, Filter.PassType.Highpass,1);
for (int i = 0; i etc etc..

In order to view your log you need to use adb. If you work in a windows environment you'd do this in a DOS command shell:

adb logcat Himanshu:* *:s -v time

Issue the above logcat command BEFORE starting your app and triggering the audio record & playback. This command is saying: Capture all log messages (.i, .d, .v, .w, .e etc.. i.e. of category: Information, Debug, Verbose, Warning and Error) and do NOT capture any other log messages, show log timestamps.

I didn't check all of the places in your code where that would also shed light on the problem. It's your code and I'm sure that you can quickly identify these places.

Actually I would have done a couple of other things also before going quite so far as you have:

1. Confirm that you can play audio samples, do this by creating a simple square wave, storing it in memory and squirting it out. You can use PCM at 16 kSamples/sec and a ~200 Hz waveform.

2. Capture recorded audio to a file and check that this is valid audio.

One other thing to mention is that you are using the AMR Narrow Band voice codec. This is not a generic audio encoding algorithm. AMR (NB) has been highly optimised for voice telephony, and as is the case for such codecs. This may be important because

Member 13073018 wrote:

som ecode and features

Perhaps your app could extend to telepathic powers, reading the mind of anybody using it?! Think about it... how can anybody offer any useful advice when you ask such a vague question. Please give us some information about what you want to achieve. I also suggest that unless you've developed an app or two before, don't waste your time looking to build one from random samples that you might be able to pull together. You really need to be realistic about what can be done starting from where you are.