Lines Matching refs:use

124 that will be exported for use by other applications, you can specify a single
133 for sharing data between only your own apps, it is preferable to use the
153 <p>When accessing a content provider, use parameterized query methods such as 
199 <p>In addition to requesting permissions, your application can use the <a
252 which is why we discourage the use of the "dangerous" permission level.</p>
271 secure web traffic.   We prefer use of HTTPS over HTTP anywhere that HTTPS is
278 wireless networks using Wi-Fi, the use of secure networking is strongly
281 <p>We have seen some applications use <a
284 accessible by other applications on the device.  Instead, you should use an Android IPC
299 Due to the limitations of SMS, we strongly recommend the use of <a
322 input validation issues and you should use those features where possible. Also
330 href="http://en.wikipedia.org/wiki/Double_free#Use_after_free">use after
345 content provider, SQL injection may be an issue.  The best defense is to use
351 <p>If you cannot use the security features above, we strongly recommend the use
363 <p>In general, the best approach for user data security is to minimize the use of APIs that access
368 application might use the hash of an an email address as a primary key, to
375 privacy policy explaining your use and storage of that data.  So following the
398 use phone identifiers such as the phone number or IMEI which may be associated
418 improper use can introduce common web security issues such as <a
424 <p>If your application does not directly use JavaScript within a {@link android.webkit.WebView}, do
434 normally reserved for Android applications.  If you use it, expose 
442 {@link android.webkit.WebView}, you may want to use the
449 use a version of {@link android.webkit webkit} that has a number of security issues.
452 content. You should also use the updatable security {@link
465 successful.  Instead use an authorization token and refresh it.</p>
469 supplied by the user, and then use a short-lived, service-specific
473 using {@link android.accounts.AccountManager}. If possible, use the
485 Alternatively, if only one application will use the credential, you might use a
498 <p>In general, try to use the highest level of pre-existing framework
499 implementation that can  support your use case.  If you need to securely
516 <p>If you need to store a key for repeated use, use a mechanism like
529 use Android system functionality for IPC such as {@link android.content.Intent},
537 If your IPC mechanism is not intended for use by other applications, set the
550 it is preferable to use {@code "signature"} level permission in the <a
560 Depending on your application requirements, you might use {@link
567 to a specific receiver, then you must use an explicit intent that declares the receiver
591 use. Each service class must have a corresponding <a
635 <p>If providing an interface that does require access controls, use {@link
645 useful to use the {@link android.os.Binder#clearCallingIdentity clearCallingIdentity()}
660 is intended for use by other applications, you
736 to want to build modular applications and use dynamic class loading.  When
738 and where you store it locally. Do not use dynamic class loading from sources
747 <p>In general, we encourage developers to use the Android SDK for
755 use native code. Linux security practices are beyond the scope of this document,