Improper Neutralization of Special Elements used i

My App data managed by the Content Provider using CursorLoaders is in SQLite database. According to Veracode Static Scan report , it is prone to SQL Injections.

But according to docs,

To avoid this problem, use a selection clause that uses ? as a replaceable parameter and a separate array of selection arguments. When you do this, the user input is bound directly to the query rather than being interpreted as part of an SQL statement. Because it's not treated as SQL, the user input can't inject malicious SQL.

public Loader<Cursor> onCreateLoader(int id, Bundle b) {
    return new CursorLoader(getActivity(), 
            NewsFeedTable.CONTENT_URI, 
            NewsFeedTable.PROJECTION, 
            "_id = ?", 
            new String[]{tid}, 
            null);
}

As shown in above code, I am doing in similar way. Also I read same in The Mobile Application Hacker's Book

If this is not sufficient measure to prevent SQL injections, how do I sanitize the sql query from the special characters? Every read suggests using parameterized PreparedStatements. Is it not default with Content Providers?

An alternative to SQLiteStatement is to use the query, insert, update, and delete methods on SQLiteDatabase as they offer parameterized statements via their use of string arrays.

I found this as a solution :

But then I read docs from here that

StringEscapeUtils.escapeSql This was a misleading method, only handling the simplest of possible SQL cases. As SQL is not Lang's focus, it didn't make sense to maintain this method.

Adding the code snippet. Report points at Line 307 where SQL Injection flaw is detected:

How should I do input validation for the special characters? Please help, to make me understand it better.

Values in selectionArgs parameters do not need to be escaped, and they must not be escaped because the escape characters would end up in the database.

There are three different cases of SQL code seen by Veracode:

values that cannot be user input (such as string literals in the source code);
values that are user input (because the come directly from, e.g., some edit box);
values that might be user input, because the tool cannot determine the source.

For marketing reasons, paid-for tools tend to inflate the problem numbers as much as possible. So Veracode reports all instances of the third case as problems.

In this case, Veracode does not know where selection comes from, so it complains. If that value is constructed by your program and never contains any user input (i.e., all user-input values are moved to ? parameters), then this is a false positive, and you must tell Veracode to shut up.