Bước 1: Thấy bức tranh toàn cảnh!
Khi bạn đến 1 thành phố mới, luôn luôn là rất tốt nếu bạn có một cái bản đồ, và biết được những con đường chính của thành phố.
Tương tự như vậy khi bạn bước lên một hành trình mới, như là học cách code, làm tương tự với tất cả các mảng lớn của thế giới code.
Lấy ví dụ, làm quen bản thân với các khái niệm của phát triển Front-End.
Biết được phát triển Back-End nghĩa là gì.
Học cách nó làm việc với nhau như thế nào.
Biết được những mảnh gì để ghép lại một ứng dụng thực tế (Những ứng dụng đơn giản như website, hoặc 1 blog).
Để ý, ở trên là tất cả những câu hỏi mà bạn có. Có thể bạn đã biết câu trả lời cho một vài câu hỏi -- thật là tuyệt.
Bước 2: Bắt đầu bằng những việc nhỏ
Bây giờ bạn đã có bức tranh lớn, đi nhỏ dần về những chủ đề cụ thể bạn muốn học. Bạn có muốn học những cơ bản về Javascript?
Bạn có muốn học cách làm việc với Youtube API?
Bạn có muốn xây dựng website đầu tiên?
Bạn hay viết nó ra một mảnh giấy
Bước 3: Noi gương (Copy)
Tìm một tài nguyên theo đúng hướng bạn đang học. Ví dụ, nếu bạn đang học với Youtube API... tìm một tài nguyên dạy bạn cách làm.
Nếu bạn đang xây dựng website đầu tiên.... tìm một tài nguyên giúp bạn làm điều đó. Noi gương là cách tốt nhất giúp bạn hoc. Hãy nhớ rằng bạn đã từng là người học rất giỏi ... khi bạn 3 tuổi. Bạn học mọi thứ thông qua việc bắt chước, bạn không đọc sách hay tham dự buổi giảng nào.
Bước 4: Noi gương mà không nhìn
Ở bước này, bạn làm lại các tutorial nhưng không nhìn vào hướng dẫn. Khi bạn làm, là lúc não của bạn bắt đầu hoạt động mạnh và bắt đầu thu nạp các kiến thức. Khi bạn vấp phải vấn đề khó, bạn có thể tra cứu, là lúc bạn nhận ra bạn hiểu cái gì và cái gì bạn vẫn cần làm sáng tỏ.
Nhớ rằng...
Đây không phải là vấn đề bộ nhớ; Không không không!
Bạn không cần nhớ, như Einstien đã nói:
"Đừng cố nhớ bất cứ thứ gì mà bạn có thể tra cứu trong sách"
Bước 5: Tạo cho mình một sheet.
Đây là phần thú vị.
Tạo cho mình một sheet những bước chỉ ra cách làm task mà bạn đang học.
Những sheet đó thật tuyệt vời.
Chúng có đầy đủ tất cả thông tin cần thiết trong một hình thái xúc tích.
Nó đơn giản và xúc tích.
Việc tạo sheet sẽ giúp bạn nhớ và giải thích nó một cách đơn giản.
Tuesday, August 15, 2017
Monday, August 14, 2017
[Network Security with Open SSL] Introduction
In today's networked world, many applications need security, and cryptography is one of the primary tools for providing that security. The primary goals of cryptography, data confidently, data integrity, authentication, and non-repudiation (accountability) can be used to thwart numerous types of network-based attacks, including eavesdroping, IP spoofing, connection hijacking, and tampering. OpenSSL is a cryptography library; it provides implementations of industry's best regarded algorithms, including encryption such as 3DES, AES, RSA, as well as message digest algorithms and message authentication codes.
Using cryptographic algorithms in a secure and reliable manner is much more difficult than most people believe. Algorithms are just building blocks un cryptographic protocols, and cryptographic protocols are notoriously difficult to get right. Cryptographer have a difficult time devising protocols that resist all known attacks, and the average developer tends to do a lot worse. For example, developers often try to secure network connections simply by encrypting data before sending it, then decrypting it on receipt. That strategy often fails to ensure the integrity of data. In many situations, attackers can tamper with data, and sometimes even recover it. Even when protocols are well designed, implementation errors are common. Most cryptographic protocols have limited applicability, such as secure online voting. However, protocols for securely communicating over an insecure medium have ubiquitous applicability. That's the basic purpose of the SSL protocol and its successor, TLS (when we generically refer to SSL, we are referring to both SSL and TLS): to provide the most common security services to arbitrary (TCP-based) network connections in such a way that the need for cryptographic expertise is minimized.
Ultimately, it would be nice if developers and administrators didn't need to know anything about cryptography or even security to protect their application. It would be nice if security was as simple as linking in a different socket library when building a program. Then OpenSSL library strives toward that ideal as much as possible, but in reality, even the SSL protocol requires a good understanding of security principles to apply securely. Indeed, most applications using SSL are susceptible to attack.
Nonetheless, SSL certainly makes securing network connections much simpler. Using SSL doesn't require any understanding of how cryptographic algorithms work. Instead, you only need to understand the basic properties importants algorithms have. Similarly, developers do not need to worry about cryptographic protocols; SSL doesn't require any understanding of its internal working in order to be used. You only need to understand how to apply the algorithm properly.
The goal of this book is to document the OpenSSL library and how to use it properly. This is book for practitioners, not for security experts.
Cryptography for the Rest of Us
For those who have never had to work with cryptography before, this section introduces you to the fundamental principles you'll need to know to understand the rest of the materials in this book. First, we'll look at the problems that cryptography aims to solve, and then we'll look at the primitives that modern cryptography provides. Anyone who has previously been exposed to the basics of cryptography should feel free to skip ahead to the next section.
Symmetric key encryption
Symmetric key algorithms encrypt and decrypt data using a single key.
The result can be sent across an insecure medium, allowing only a recipient who has the original key to decrypt the message, which is done by passing the ciphertext and the key to a decryption algorithm. Obviously, the key must remain secret for this scheme to be effective.
The primary disadvantages of symmetric key algorithms is that the key must remain secret at all times. In particular, exchanging secret keys can be difficult, since you'll usually want to exchange keys on the same medium that you're trying to use encryption to protect. Sending the key in the clear before you use it leaves open the possibility of an attacker recording the key before you even begin to send data.
One solution to the key distribution problem is to use a cryptographic key exchange protocol. OpenSSL provides the Diffie-Hellman protocol for this purpose, which allow for key agreement without actually divulging (tiết lộ) the key on the network. However, D-H doesn't guarantee the identity of the party with whom you are exchanging keys. Some sort of authentication mechanism is necessary to ensure that you don't accidently exchange keys with an attacker.
Security is related to the length to the key. Longer key lengths are, of course, better. To ensure security, you should only use key lengths of 80 bits or higher. While 64-bit keys may be secure, they likely will not be for long, whereas 80-bit keys should be secure for at least a few years to come. AES support only 128-bit keys and higher, while 3DES has a fixed 112 bits of effective security. Both of these should be secure fir all cryptographic needs for the foreseeable future. Larger keys are probably unnecessary.
Public key encryption
Public key cryptography suggest a solution to the key distribution problem that plagues symmetric cryptography. In the most popular form of public key cryptography, each party has two keys, one that must remain secret (the private key) and one that can be freely distributed (the public key). The two keys have a special mathematical relationship. For Alice to send a message to Bob using public key encryption, Alice must first have Bob's public key. She then encrypt her message using Bob's public key, and delivers it. Once encrypted, only someone who has Bob's private key can successfully decrypt the message (hopefully, that's only Bob).
Public key encryption solve the problem of key distribution, assuming there is some way to find Bob's public key and ensure that the key really belong to Bob. In practice, public key are passed around with a bunch of supporting information called "certificate", and those certificates are validated by trusted third parties. Often, a trusted third party is an organization that does research (such as credit checks) on people who wish to have their certificates validated. SSL uses trusted third parties to held address the key distribution problem.
Public key cryptography has a significant draw back, though: it is intolerably slow for large message. Symmetric key cryptography can usually be done quickly enough to encrypt and decrypt all the network traffic a machine can manage. Public key cryptography is generally limited by the speed of the cryptography, not the bandwidth going into the computer, particularly on server machines that need to handle multiple connections simultaneously.
As a result, most systems that use public key cryptography, SSL included, use it as little as possible. Generally, public key encryption is used to agree on an encryption key for a symmetric algorithm, and then all further encryption is done using symmetric algorithm. Therefore, public key encryption algorithms are primarily used in key exchange protocols and when non-repudiation is required.
RSA is the most popular public key encryption algorithm. The D-H key exchange protocol is based on public key technology and can be used to achieve the same ends by exchanging a symmetric key, which is used to perform actual data encryption and decryption. For public key schemes to be effective, there usually needs to be an authentication mechanism involving a trusted third party that is separate from the encryption itself. Most often, digital signature schemes, which we discuss below, provide the necessary authentication.
Key in public key algorithms are essentially large numbers with particular properties. Therefore, bit length of keys in public key ciphers aren't directly comparable to symmetric algorithms. With public key encryption algorithms, you should use keys of 1024 bits or more to ensure reasonable security. 512-bit keys are probably too weak. Anything larger than 2048 bits maybe too slow, and changes are it will not buy security that is much more practical. Recently, there's been some concern that 1024-bit keys are too weak, but as of this writing, there hasn't been conclusive proof. Certainly, 1024-bits is a bare minimum for practical security from short-term attacks. If your keys potentially need to stay protected for years, then you might want to go ahead and use 2048-bit keys.
Cryptographic hash functions and Message Authentication Codes
Cryptographic hash functions are essentially checksum algorithms with special properties. You pass data to the hash function, and it outputs a fixed-size checksum, often called a message digest, or simply digest for short. Passing identical data into the hash function twice will always yield identical results. However, the results gives away no information about the data input to the function. Additionally, it should be practically impossible to find two inputs that produce the same message digest. Generally, when we discuss such functions, we are talking about one-way functions. That is, it should not be possible to take the output and algorithmically reconstruct the input under circumstances. There are certainly reversible hash functions, but we do not consider such things in the scope of this book.
For general-purpose usage, a minimally secure cryptographic hash algorithm should have a digest as large as a minimally secure symmetric key algorithm. MD5 and SHA1 are the most popular one-way cryptographic hash functions. MD5's digest length is only 128 bits, whereas SHA1's is 160 bits. For some uses, MD5's key length is suitable, and for others, it is risky. To be safe, we recommend using only cryptographic hash algorithm that yield 160-bit digests or larger, unless you need to support legacy algorithm. In addition, MD5 is widely considered "nearly broken" due to some cryptographic weaknesses in part of the algorithm. Therefore, we recommend that you avoid using MD5 in any new applications.
Cryptographic hash functions have been put to many uses. They are frequently used as part of a password storage solution. In such circumstances, logins are checked by running the hash functions over the password and some additional data, and checking it against stored value. That way, the server doesn't have to store the actual password, so a well-chosen password will be safe even if an attacker manages to get a hold of the password database.
Another thing people like to do with cryptographic hashes is to release them along side a software release. For example, OpenSSL might be released alongside a MD5 checksum of the archive. When you download the archive, you can also download the checksum. Then you can compute the checksum over the archive and see if the computed checksum matches the downloaded checksum. You might hope that if the two checksum match, then you securely downloaded the actual released file, and did not get some modified version with a Trojan horse in it. Unfortunately, that isn't the case, because there is no secret involved. An attacker can replace the archive with a modified version, and replace the checksum with a valid value. This is possible because the message digest algorithm is public, and there is no secret information input to it.
If you share a secret key with the software distributor, then the distributor could combine the archive with the secret key to produce a message digest that an attacker shouldn't be able to forge, sine he wouldn't have the secret. Schemes for using keyed hashes, i.e., hashes involving a secret key, are called Message Authentication Codes (MACs). MACs are often used to provide message integrity for general-purpose data transfer, whether encrypted or not. Indeed, SSL uses MACs for this purpose.
The most widely used MAC, and the only one currently supported in SSL and in OpenSSL, in HMAC. HMAC can be used with any message digest algorithm.
Digital signatures
For many applications, MACs are not very useful, because they require agreeing on a shared secret. It would be nice to be able to authenticate message without needing to share a secret. Public key cryptography makes this possible. If Alice signs a message with her secret signing key, then anyone can use her public key to verify that she signed the message. RSA provides for digital signing. Essentially, the public key and private key are interchangeable. If Alice encrypts a message with her private key, any one can decrypt it. If Alice didn't encrypt the message, using her public key to decrypt the message would result in garbage.
There is also a popular scheme called DSA (Digital Signature Algorithm), which the SSL protocol and the OpenSSL library both support.
Giống như mã hóa khóa công khai, chữ ký số rất là chậm. Để tăng tốc độ, thuật toán thường không thực hiện trên toàn bộ bản tin được ký. Thay vào đó, bản tin được băm, và sau đó giá trị băm được ký. Tuy vậy, việc ký vẫn đắt đỏ. Chính bởi lý do đó, MACs thường là giải pháp ưa thích nếu có sự trao đổi khóa xảy ra.
Chữ ký số được sử dụng rộng rãi trong việc quản lý chứng chỉ. Nếu Alice muốn chứng thực chứng chỉ của Bob, cố ấy có thể ký nó với khóa bí mật của cô ấy. Sau đó, Bob đính kèm
Using cryptographic algorithms in a secure and reliable manner is much more difficult than most people believe. Algorithms are just building blocks un cryptographic protocols, and cryptographic protocols are notoriously difficult to get right. Cryptographer have a difficult time devising protocols that resist all known attacks, and the average developer tends to do a lot worse. For example, developers often try to secure network connections simply by encrypting data before sending it, then decrypting it on receipt. That strategy often fails to ensure the integrity of data. In many situations, attackers can tamper with data, and sometimes even recover it. Even when protocols are well designed, implementation errors are common. Most cryptographic protocols have limited applicability, such as secure online voting. However, protocols for securely communicating over an insecure medium have ubiquitous applicability. That's the basic purpose of the SSL protocol and its successor, TLS (when we generically refer to SSL, we are referring to both SSL and TLS): to provide the most common security services to arbitrary (TCP-based) network connections in such a way that the need for cryptographic expertise is minimized.
Ultimately, it would be nice if developers and administrators didn't need to know anything about cryptography or even security to protect their application. It would be nice if security was as simple as linking in a different socket library when building a program. Then OpenSSL library strives toward that ideal as much as possible, but in reality, even the SSL protocol requires a good understanding of security principles to apply securely. Indeed, most applications using SSL are susceptible to attack.
Nonetheless, SSL certainly makes securing network connections much simpler. Using SSL doesn't require any understanding of how cryptographic algorithms work. Instead, you only need to understand the basic properties importants algorithms have. Similarly, developers do not need to worry about cryptographic protocols; SSL doesn't require any understanding of its internal working in order to be used. You only need to understand how to apply the algorithm properly.
The goal of this book is to document the OpenSSL library and how to use it properly. This is book for practitioners, not for security experts.
Cryptography for the Rest of Us
For those who have never had to work with cryptography before, this section introduces you to the fundamental principles you'll need to know to understand the rest of the materials in this book. First, we'll look at the problems that cryptography aims to solve, and then we'll look at the primitives that modern cryptography provides. Anyone who has previously been exposed to the basics of cryptography should feel free to skip ahead to the next section.
Symmetric key encryption
Symmetric key algorithms encrypt and decrypt data using a single key.
The result can be sent across an insecure medium, allowing only a recipient who has the original key to decrypt the message, which is done by passing the ciphertext and the key to a decryption algorithm. Obviously, the key must remain secret for this scheme to be effective.
The primary disadvantages of symmetric key algorithms is that the key must remain secret at all times. In particular, exchanging secret keys can be difficult, since you'll usually want to exchange keys on the same medium that you're trying to use encryption to protect. Sending the key in the clear before you use it leaves open the possibility of an attacker recording the key before you even begin to send data.
One solution to the key distribution problem is to use a cryptographic key exchange protocol. OpenSSL provides the Diffie-Hellman protocol for this purpose, which allow for key agreement without actually divulging (tiết lộ) the key on the network. However, D-H doesn't guarantee the identity of the party with whom you are exchanging keys. Some sort of authentication mechanism is necessary to ensure that you don't accidently exchange keys with an attacker.
Security is related to the length to the key. Longer key lengths are, of course, better. To ensure security, you should only use key lengths of 80 bits or higher. While 64-bit keys may be secure, they likely will not be for long, whereas 80-bit keys should be secure for at least a few years to come. AES support only 128-bit keys and higher, while 3DES has a fixed 112 bits of effective security. Both of these should be secure fir all cryptographic needs for the foreseeable future. Larger keys are probably unnecessary.
Public key encryption
Public key cryptography suggest a solution to the key distribution problem that plagues symmetric cryptography. In the most popular form of public key cryptography, each party has two keys, one that must remain secret (the private key) and one that can be freely distributed (the public key). The two keys have a special mathematical relationship. For Alice to send a message to Bob using public key encryption, Alice must first have Bob's public key. She then encrypt her message using Bob's public key, and delivers it. Once encrypted, only someone who has Bob's private key can successfully decrypt the message (hopefully, that's only Bob).
Public key encryption solve the problem of key distribution, assuming there is some way to find Bob's public key and ensure that the key really belong to Bob. In practice, public key are passed around with a bunch of supporting information called "certificate", and those certificates are validated by trusted third parties. Often, a trusted third party is an organization that does research (such as credit checks) on people who wish to have their certificates validated. SSL uses trusted third parties to held address the key distribution problem.
Public key cryptography has a significant draw back, though: it is intolerably slow for large message. Symmetric key cryptography can usually be done quickly enough to encrypt and decrypt all the network traffic a machine can manage. Public key cryptography is generally limited by the speed of the cryptography, not the bandwidth going into the computer, particularly on server machines that need to handle multiple connections simultaneously.
As a result, most systems that use public key cryptography, SSL included, use it as little as possible. Generally, public key encryption is used to agree on an encryption key for a symmetric algorithm, and then all further encryption is done using symmetric algorithm. Therefore, public key encryption algorithms are primarily used in key exchange protocols and when non-repudiation is required.
RSA is the most popular public key encryption algorithm. The D-H key exchange protocol is based on public key technology and can be used to achieve the same ends by exchanging a symmetric key, which is used to perform actual data encryption and decryption. For public key schemes to be effective, there usually needs to be an authentication mechanism involving a trusted third party that is separate from the encryption itself. Most often, digital signature schemes, which we discuss below, provide the necessary authentication.
Key in public key algorithms are essentially large numbers with particular properties. Therefore, bit length of keys in public key ciphers aren't directly comparable to symmetric algorithms. With public key encryption algorithms, you should use keys of 1024 bits or more to ensure reasonable security. 512-bit keys are probably too weak. Anything larger than 2048 bits maybe too slow, and changes are it will not buy security that is much more practical. Recently, there's been some concern that 1024-bit keys are too weak, but as of this writing, there hasn't been conclusive proof. Certainly, 1024-bits is a bare minimum for practical security from short-term attacks. If your keys potentially need to stay protected for years, then you might want to go ahead and use 2048-bit keys.
Cryptographic hash functions and Message Authentication Codes
Cryptographic hash functions are essentially checksum algorithms with special properties. You pass data to the hash function, and it outputs a fixed-size checksum, often called a message digest, or simply digest for short. Passing identical data into the hash function twice will always yield identical results. However, the results gives away no information about the data input to the function. Additionally, it should be practically impossible to find two inputs that produce the same message digest. Generally, when we discuss such functions, we are talking about one-way functions. That is, it should not be possible to take the output and algorithmically reconstruct the input under circumstances. There are certainly reversible hash functions, but we do not consider such things in the scope of this book.
For general-purpose usage, a minimally secure cryptographic hash algorithm should have a digest as large as a minimally secure symmetric key algorithm. MD5 and SHA1 are the most popular one-way cryptographic hash functions. MD5's digest length is only 128 bits, whereas SHA1's is 160 bits. For some uses, MD5's key length is suitable, and for others, it is risky. To be safe, we recommend using only cryptographic hash algorithm that yield 160-bit digests or larger, unless you need to support legacy algorithm. In addition, MD5 is widely considered "nearly broken" due to some cryptographic weaknesses in part of the algorithm. Therefore, we recommend that you avoid using MD5 in any new applications.
Cryptographic hash functions have been put to many uses. They are frequently used as part of a password storage solution. In such circumstances, logins are checked by running the hash functions over the password and some additional data, and checking it against stored value. That way, the server doesn't have to store the actual password, so a well-chosen password will be safe even if an attacker manages to get a hold of the password database.
Another thing people like to do with cryptographic hashes is to release them along side a software release. For example, OpenSSL might be released alongside a MD5 checksum of the archive. When you download the archive, you can also download the checksum. Then you can compute the checksum over the archive and see if the computed checksum matches the downloaded checksum. You might hope that if the two checksum match, then you securely downloaded the actual released file, and did not get some modified version with a Trojan horse in it. Unfortunately, that isn't the case, because there is no secret involved. An attacker can replace the archive with a modified version, and replace the checksum with a valid value. This is possible because the message digest algorithm is public, and there is no secret information input to it.
If you share a secret key with the software distributor, then the distributor could combine the archive with the secret key to produce a message digest that an attacker shouldn't be able to forge, sine he wouldn't have the secret. Schemes for using keyed hashes, i.e., hashes involving a secret key, are called Message Authentication Codes (MACs). MACs are often used to provide message integrity for general-purpose data transfer, whether encrypted or not. Indeed, SSL uses MACs for this purpose.
The most widely used MAC, and the only one currently supported in SSL and in OpenSSL, in HMAC. HMAC can be used with any message digest algorithm.
Digital signatures
For many applications, MACs are not very useful, because they require agreeing on a shared secret. It would be nice to be able to authenticate message without needing to share a secret. Public key cryptography makes this possible. If Alice signs a message with her secret signing key, then anyone can use her public key to verify that she signed the message. RSA provides for digital signing. Essentially, the public key and private key are interchangeable. If Alice encrypts a message with her private key, any one can decrypt it. If Alice didn't encrypt the message, using her public key to decrypt the message would result in garbage.
There is also a popular scheme called DSA (Digital Signature Algorithm), which the SSL protocol and the OpenSSL library both support.
Giống như mã hóa khóa công khai, chữ ký số rất là chậm. Để tăng tốc độ, thuật toán thường không thực hiện trên toàn bộ bản tin được ký. Thay vào đó, bản tin được băm, và sau đó giá trị băm được ký. Tuy vậy, việc ký vẫn đắt đỏ. Chính bởi lý do đó, MACs thường là giải pháp ưa thích nếu có sự trao đổi khóa xảy ra.
Chữ ký số được sử dụng rộng rãi trong việc quản lý chứng chỉ. Nếu Alice muốn chứng thực chứng chỉ của Bob, cố ấy có thể ký nó với khóa bí mật của cô ấy. Sau đó, Bob đính kèm
Friday, August 4, 2017
Some useful links for Android Developer
1. Need to change themes for Android Studio. Download themes from this link:
http://color-themes.com/?view=index
2. Need to do some practice with Google, go to Google CodeLab:
https://codelabs.developers.google.com
3. How to handle FileUriExposeException?
4. Exo Player guide and source code:
http://color-themes.com/?view=index
2. Need to do some practice with Google, go to Google CodeLab:
https://codelabs.developers.google.com
3. How to handle FileUriExposeException?
- https://inthecheesefactory.com/blog/how-to-share-access-to-file-with-fileprovider-on-android-nougat/en
- https://medium.com/@ali.muzaffar/what-is-android-os-fileuriexposedexception-and-what-you-can-do-about-it-70b9eb17c6d0
4. Exo Player guide and source code:
Friday, May 26, 2017
Android Studio Shortcuts
Android Studio is based on IntelliJ IDEA and for those new to this IDE, this refcard article will be of help.
Mastering a tool is important to become a more efficient developer. I'll see some very helpful keyboard shortcuts that can save a little bit of time and quite a bit of frustration. We need shortcuts to be on top. Following are most essential Android Studio shortcuts we need.
Mastering a tool is important to become a more efficient developer. I'll see some very helpful keyboard shortcuts that can save a little bit of time and quite a bit of frustration. We need shortcuts to be on top. Following are most essential Android Studio shortcuts we need.
Navigation Shortcuts
| Shortcut Description | Android Studio Shortcut |
|---|---|
| Go to class | Ctrl + N |
| Go to file | Ctrl + Shift + N |
| Navigate open tabs | ALT + Left-Arrow; ALT + Right-Arrow |
| Lookup recent files | CTRL + E |
| Go to line | CTRL + G |
| Navigate to last edit location | CTRL + SHIFT + BACKSPACE |
| Go to declaration | CTRL + B |
| Go to implementation | CTRL + ALT + B |
| Go to source | F4 |
| Go to super Class | CTRL + U |
| Show Call hierarchy | Ctrl + Alt + H |
| Search in path/project | CTRL + SHIFT + F |
Programming Shortcuts
| Shortcut Description | Android Studio Shortcut |
|---|---|
| Reformat code | CTRL + ALT + L |
| Optimize imports | CTRL + ALT + O |
| Code Completion | CTRL + SPACE |
| Issue quick fix | ALT + ENTER |
| Surround code block | CTRL + ALT + T |
| Rename and refactor | Shift + F6 |
| Line Comment or Uncomment | CTRL + / |
| Block Comment or Uncomment | CTRL + SHIFT + / |
| Go to previous/next method | ALT + UP/DOWN |
| Show parameters for method | CTRL + P |
| Quick documentation lookup | CTRL + Q |
General Shortcuts
| Shortcut Description | Android Studio Shortcut |
|---|---|
| Delete line | CTRL + Y |
| Safe Delete | Alt + DELETE |
| Close Active Tab | CTRL + F4 |
| Build and run | SHIFT + F10 |
| Build | CTRL + F9 |
| All purpose (Meta)Shortcut | CTRL + SHIFT + A |
Subscribe to:
Posts (Atom)
-
In today's networked world, many applications need security, and cryptography is one of the primary tools for providing that security. T...
-
Android Studio is based on IntelliJ IDEA and for those new to this IDE, this refcard article will be of help. Mastering a tool is importan...
-
1. Need to change themes for Android Studio. Download themes from this link: http://color-themes.com/?view=index 2. Need to do some p...
