| /external/autotest/docs/ |
| D | loading-autotest-extension-on-device.md | 1 # Loading autotestPrivate extension on your device
5 the extension on your device.
13 checkout. To load a test image on your device follow [these steps] from the
20 autotest extension on your device](#Loading-autotest-extension-on-your-device)
24 1. Run in your workstation:
39 1. Reboot your device for rootfs changes to take effect. Run:
45 ## Loading autotest extension on your device
47 1. Enter a Chrome OS chroot. Inside of your Chrome OS checkout directory run:
51 1. From inside your Chrome OS chroot run:
55 This will install the autotestPrivate extension manifest to your device.
[all …]
|
| /external/python/google-api-python-client/docs/ |
| D | auth.md | 3 …omplished. For all API calls, your application needs to be authenticated. When an API accesses a u…
11 … Your application must authenticate itself as an application belonging to your Google API Console …
13 …key:** To authenticate your application, use an [API key](api-keys.md) for your API Console projec…
15 …Warning:** Keep your API key private. If someone obtains your key, they could use it to consume yo…
19 …vate data must grant your application access. Therefore, your application must be authenticated, t…
21 …When your application requests access to user data, the request must include one or more scopes. T…
23 …and access tokens:** When a user grants your application access, the OAuth 2.0 authorization serve…
25 > **Warning:** Keep refresh and access tokens private. If someone obtains your tokens, they could u…
27 …your application and are used to acquire tokens. They are created for your project on the [API Con…
33 …:** Keep your client secret private. If someone obtains your client secret, they could use it to c…
|
| D | oauth-web.md | 11 ### Enable APIs for your project
13 …PIs needs to enable those APIs in the API Console. To enable the appropriate APIs for your project:
16 1. Select the project associated with your application. Create a project if you do not have one alr…
17 …the **Library** page to find each API that your application will use. Click on each API and enable…
21 …uth 2.0 server. The following steps explain how to create credentials for your project. Your appli…
37 We recommend that you <a href="#protectauthcode">design your app's auth
38 endpoints</a> so that your application does not expose authorization
42 … creating your credentials, download the **client_secret.json** file from the API Console. Securel…
44 …de to your application—for example, on GitHub—store the **client_secret.json** file outside of you…
48 …your application to only request access to the resources that it needs while also enabling users t…
[all …]
|
| /external/slf4j/ |
| D | README.md | 8 If you are interested in improving SLF4J, great! The SLF4J community looks forward to your contribu…
10 …e [slf4j-dev mailing list](http://www.slf4j.org/mailing-lists.html) about your proposed change. Al…
11 …-ch/slf4j. Ideally, create a new branch from your fork for your contribution to make it easier to …
12 … Make your changes on the branch you hopefuly created in Step 2. Be sure that your code passes exi…
13 4. Push your changes to your fork/branch in github. Don't push it to your master! If you do it will…
14 5. Submit a pull request to SLF4J from from your commit page on github.
|
| /external/python/jinja/ |
| D | CONTRIBUTING.rst | 13 your own code:
28 Include the following information in your post:
33 your own code.
36 - List your Python and Jinja versions. If possible, check if this
52 Include the following in your patch:
54 - Use `Black`_ to format your code. This and other tools will run
57 - Include tests if your patch adds or changes code. Make sure the test
58 fails without your patch.
73 - Configure git with your `username`_ and `email`_.
77 $ git config --global user.name 'your name'
[all …]
|
| /external/zstd/ |
| D | CONTRIBUTING.md | 14 We actively welcome your pull requests.
16 1. Fork the repo and create your branch from `dev`.
20 5. Make sure your code lints.
24 In order to accept your pull request, we need you to submit a CLA. You only need
27 Complete your CLA here: <https://code.facebook.com/cla>
37 * Checkout your fork of zstd if you have not already
42 * Update your local dev branch
48 * Make a new branch on your fork about the topic you're developing for
60 * Note: run local tests to ensure that your changes didn't break existing functionality
71 … * Before sharing anything to the community, make sure that all CI tests pass on your local fork.
[all …]
|
| /external/bazelbuild-rules_android/ |
| D | CONTRIBUTING.md | 5 **Before we can use your code, you must sign the
9 The CLA is necessary mainly because you own the copyright to your changes,
10 even after your contribution becomes part of our codebase, so we need your
11 permission to use and distribute your code. We also need to be sure of
13 your code infringes on other people's patents. You don't have to sign
14 the CLA until after you've submitted your code for review and a member has
15 approved it, but you must do it before we can put your code into our codebase.
24 1. Explain your idea and discuss your plan with members of the team. The best
28 1. Prepare a git commit with your change. Don't forget to
38 will test your change automatically on supported platforms. Once everything
[all …]
|
| /external/google-breakpad/docs/ |
| D | mac_breakpad_starter_guide.md | 3 This document is a step-by-step recipe to get your Mac client app to build with
6 ## Preparing a binary build of Breakpad for use in your tree
9 build it as a dependency of your project. The former is recommended, and
12 change nearly often enough as your application's will.
19 * Execute `cp -R client/mac/build/Release/Breakpad.framework <location in your
27 Inside your application's framework, add the Breakpad.Framework to your
30 to your application.
32 ## Copy Breakpad into your Application Package
34 Copy Breakpad into your Application Package, so it will be around at run time.
36 Go to the Targets section of your Xcode Project window. Hit the disclosure
[all …]
|
| /external/llvm-project/llvm/utils/vscode/llvm/ |
| D | vsc-extension-quickstart.md | 1 # Welcome to your VS Code Extension
5 * This folder contains all of the files necessary for your extension.
6 …t file in which you declare your language support and define the location of the grammar file that…
13 * Press `F5` to open a new window with your extension loaded.
14 * Create a new file with a file name suffix matching your language.
20 …so reload (`Ctrl+R` or `Cmd+R` on Mac) the VS Code window with your extension to load your changes.
26 ## Install your extension
28 * To start using your extension with Visual Studio Code copy it into the `<user home>/.vscode/exten…
29 * To share your extension with the world, read on https://code.visualstudio.com/docs about publishi…
|
| /external/tensorflow/tensorflow/lite/g3doc/guide/ |
| D | build_ios.md | 3 This document describes how to build TensorFlow Lite iOS library on your own.
7 details on how to use them in your iOS projects.
13 changes in your iOS app or you prefer using static framework to our provided
48 Note: This step is not necessary if (1) you are using Bazel for your app, or (2)
50 cases, skip to the [Use in your own application](#use_in_your_own_application)
62 `bazel-bin/tensorflow/lite/ios/` directory under your TensorFlow root directory.
80 under `bazel-bin/tensorflow/lite/ios/` directory under your TensorFlow root
84 ## Use in your own application
97 `TensorFlowLiteObjC` pod based on the language in which your app is written, but
107 1. Make changes to the Swift or Objective-C APIs in your `tensorflow` checkout.
[all …]
|
| /external/flatbuffers/ |
| D | CONTRIBUTING.md | 8 Before we can use your code, you must sign the
11 copyright to your changes, even after your contribution becomes part of our
12 codebase, so we need your permission to use and distribute your code. We also
14 know that your code infringes on other people's patents. You don't have to sign
15 the CLA until after you've submitted your code for review and a member has
16 approved it, but you must do it before we can put your code into our codebase.
18 us first through the issue tracker with your idea so that we can help out and
34 * If your PR consists of multiple commits which are successive improvements /
35 fixes to your first commit, consider squashing them into a single commit
36 (`git rebase -i`) such that your PR is a single commit on top of the current
|
| /external/oss-fuzz/projects/libaom/ |
| D | README.md | 10 1. Go to your own fork of the repo, which will be at
14 in terminal. Now you have a local repo, and **your fork** of the remote repo
15 will be called “**origin**” in your git config.
27 1. Go to your repo:
32 1. Make your changes and commit them locally with “git commit”
33 1. Push your changes to your fork on github
35 * (This will create a branch of the same name “new_feature_xyz” on your
37 1. Open your fork in browser and click on “Compare & pull request” and follow
44 * Delete “new_feature_xyz” branch on your fork using the “Delete branch”
48 * Sync your local repo and your fork with upstream repo:
|
| /external/flatbuffers/docs/source/ |
| D | CONTRIBUTING.md | 8 Before we can use your code, you must sign the
11 copyright to your changes, even after your contribution becomes part of our
12 codebase, so we need your permission to use and distribute your code. We also
14 know that your code infringes on other people's patents. You don't have to sign
15 the CLA until after you've submitted your code for review and a member has
16 approved it, but you must do it before we can put your code into our codebase.
18 us first through the issue tracker with your idea so that we can help out and
34 * If your PR consists of multiple commits which are successive improvements /
35 fixes to your first commit, consider squashing them into a single commit
36 (`git rebase -i`) such that your PR is a single commit on top of the current
|
| /external/auto/value/userguide/ |
| D | practices.md | 13 Avoid mutable types, including arrays, for your properties, especially if you
14 make your accessor methods `public`. The generated accessors don't copy the
15 field value on its way out, so you'd be exposing your internal state.
17 Note that this doesn't mean your factory method can't *accept* mutable types as
36 You should essentially *never* need an alternative implementation of your
38 framework. If your behavior has enough complexity (or dependencies) that it
47 reference from your source code: the call from your static factory method to the
55 Consider that other developers will try to read and understand your value class
56 while looking only at your hand-written class, not the actual (generated)
57 implementation class. If you mark your concrete methods `final`, they won't have
[all …]
|
| /external/skia/site/docs/dev/contrib/ |
| D | submit.md | 15 First create a branch for your changes:
22 After making your changes, create a commit
29 If your branch gets out of date, you will need to update it:
45 Unit tests are best, but if your change touches rendering and you can't think of
47 your change is in the GPU code, you may not be able to write it as part of the
53 For your code to be accepted into the codebase, you must complete the
58 and send it to us as described on that page. Add your (or your organization's)
59 name and contact info to the AUTHORS file as a part of your CL.
77 appropriate reviewers for your change. The button is located here:
83 [skia-review](http://skia-review.googlesource.com). Use `git cl` to upload your
[all …]
|
| /external/skqp/site/dev/contrib/ |
| D | submit.md | 16 First create a branch for your changes:
23 After making your changes, create a commit
30 If your branch gets out of date, you will need to update it:
47 Unit tests are best, but if your change touches rendering and you can't think of
48 an automated way to verify the results, consider writing a GM test. Also, if your
55 For your code to be accepted into the codebase, you must complete the
61 and send it to us as described on that page. Add your (or your organization's)
62 name and contact info to the AUTHORS file as a part of your CL.
80 Use `git cl` to upload your change:
92 (https://skia-review.googlesource.com/c/4559/), indicating where your changelist
[all …]
|
| /external/python/cpython2/Doc/howto/ |
| D | pyporting.rst | 12 use, it is good to have your project available for both major releases of
29 To make your project be single-source Python 2/3 compatible, the basic steps
36 #. Use Futurize_ (or Modernize_) to update your code (e.g. ``pip install future``)
37 #. Use Pylint_ to help make sure you don't regress on your Python 3 support
39 #. Use caniusepython3_ to find out which of your dependencies are blocking your
41 #. Once your dependencies are no longer blocking you, use continuous integration
44 #. Consider using optional static type checking to make sure your type usage
45 works in both Python 2 & 3 (e.g. use mypy_ to check your typing under both
53 **today**! Even if your dependencies are not supporting Python 3 yet that does
54 not mean you can't modernize your code **now** to support Python 3. Most changes
[all …]
|
| /external/python/cpython3/Doc/howto/ |
| D | pyporting.rst | 12 use, it is good to have your project available for both major releases of
29 To make your project be single-source Python 2/3 compatible, the basic steps
36 #. Use Futurize_ (or Modernize_) to update your code (e.g. ``python -m pip install future``)
37 #. Use Pylint_ to help make sure you don't regress on your Python 3 support
39 #. Use caniusepython3_ to find out which of your dependencies are blocking your
41 #. Once your dependencies are no longer blocking you, use continuous integration
44 #. Consider using optional static type checking to make sure your type usage
45 works in both Python 2 & 3 (e.g. use mypy_ to check your typing under both
59 **today**! Even if your dependencies are not supporting Python 3 yet that does
60 not mean you can't modernize your code **now** to support Python 3. Most changes
[all …]
|
| /external/brotli/ |
| D | CONTRIBUTING.md | 5 Before we can use your code, you must sign the
9 copyright to your changes, even after your contribution becomes part of our
10 codebase, so we need your permission to use and distribute your code. We also
12 know that your code infringes on other people's patents. You don't have to sign
13 the CLA until after you've submitted your code for review and a member has
14 approved it, but you must do it before we can put your code into our codebase.
16 us first through the issue tracker with your idea so that we can help out and
|
| /external/oboe/ |
| D | CONTRIBUTING.md | 4 Before we can use your code, you must sign the
8 copyright to your changes, even after your contribution becomes part of our
9 codebase, so we need your permission to use and distribute your code. We also
11 know that your code infringes on other people's patents. You don't have to sign
12 the CLA until after you've submitted your code for review and a member has
13 approved it, but you must do it before we can put your code into our codebase.
15 us first through the issue tracker with your idea so that we can help out and
|
| /external/walt/ |
| D | CONTRIBUTING.md | 4 Before we can use your code, you must sign the
8 copyright to your changes, even after your contribution becomes part of our
9 codebase, so we need your permission to use and distribute your code. We also
11 know that your code infringes on other people's patents. You don't have to sign
12 the CLA until after you've submitted your code for review and a member has
13 approved it, but you must do it before we can put your code into our codebase.
15 us first through the issue tracker with your idea so that we can help out and
|
| /external/libprotobuf-mutator/ |
| D | CONTRIBUTING | 4 Before we can use your code, you must sign the
8 copyright to your changes, even after your contribution becomes part of our
9 codebase, so we need your permission to use and distribute your code. We also
11 know that your code infringes on other people's patents. You don't have to sign
12 the CLA until after you've submitted your code for review and a member has
13 approved it, but you must do it before we can put your code into our codebase.
15 us first through the issue tracker with your idea so that we can help out and
|
| /external/drrickorang/LoopbackApp/ |
| D | CONTRIBUTING | 4 Before we can use your code, you must sign the
8 copyright to your changes, even after your contribution becomes part of our
9 codebase, so we need your permission to use and distribute your code. We also
11 know that your code infringes on other people's patents. You don't have to sign
12 the CLA until after you've submitted your code for review and a member has
13 approved it, but you must do it before we can put your code into our codebase.
15 us first through the issue tracker with your idea so that we can help out and
|
| /external/google-java-format/ |
| D | CONTRIBUTING.md | 6 Before we can use your code, you must sign the [Google Individual Contributor
10 copyright to your changes, even after your contribution becomes part of our
11 codebase, so we need your permission to use and distribute your code. We also
13 know that your code infringes on other people's patents. You don't have to sign
14 the CLA until after you've submitted your code for review and a member has
15 approved it, but you must do it before we can put your code into our codebase.
17 us first through the issue tracker with your idea so that we can help out and
|
| /external/oss-fuzz/ |
| D | CONTRIBUTING.md | 5 Before we can use your code, you must sign the
8 copyright to your changes, even after your contribution becomes part of our
9 codebase, so we need your permission to use and distribute your code. We also
11 know that your code infringes on other people's patents. You don't have to sign
12 the CLA until after you've submitted your code for review and a member has
13 approved it, but you must do it before we can put your code into our codebase.
15 us first through the issue tracker with your idea so that we can help out and
|