Денис Загаевский

Это вообще разные вещи.
Нужно отличать изучение API, от изучения технологии. Если вы хотите выучить просто API, учите что угодно, ибо разницу заметите только, когда поймёте основы, базу.

OpenGL проектировался когда были другие архитектуры железа. Мультипроцессорность была только в теории, и считалась уделом суперкомпьютеров и ненужной для пользовательских ПК.
Можно привести аналогию: OpenGL == C++, Vulkan == асинхронный Assembler + hardware threads. Например, в C++ сейчас довольно много архитектурных косяков, которые пытаются решить новыми стандартами, объявляют какие вещи устаревшими, потому что они концептуально неверны и не подходят под современные реалии.
Но, при этом, вы можете всё то же самое написать на ассемблере, но нужно намного лучше понимать, как работает процессор и ОС, самому писать примитивы синхронизации, и т. п.

Для этих же целей и создавался вулкан. Для программирования на нём, нужно знать все тонкости железки, читать кучи пейперов от той же НВидии, исследовать, придумывать новые фичи для современных архитектур с нуля, которые изначально были придуманы в OpenGL, но для старого железа.
Т. е. на Вулкане нужно делать больше руками, больше оптимизировать. Вместо одного вызова функции OpenGL, на вулкане придётся несколько сотен строк написать. При этом, если вы не понимаете какой-то одной тонкости, вы сделаете менее эффективнее то, что изначально было хорошо реализовано в OpenGL. К тому же, OpenGL умеет выбрасывать ошибки, в случае, когда вы где-то накосячили. Вулкан же их не выбрасывает, он полагается на то, что вы уже знаете как этим пользоваться. Точно так же, как ассемблер просто меняет состояние регистров, у него нет понятия ошибки. Как интерпретировать эти регистры, зависит от того, насколько хорошо разработчик читал мануал к процессору.

В итоге, я бы ответил так:

Если вы будете заниматься графикой как наукой, дико задротить а-ля Кармак в студенчестве с его движками, что-то исследовать, писать какие-то гениальные алгоритмы, защищать на этом диссертации, публиковать их, рассказывать потом на конференции, как вы круто справились с какой-то насущной задачей, повысили производительность, то тогда учите Vulkan. Vulkan — это именно про графику как технологию, про производительность, про инжиниринг и архитектурный дизайн, а не про API и само программирование. С вулканом придётся больше сидеть с диаграммами, документациями и строить архитектуру, придумывать методы взаимодействия частей этой архитектуры, синхронизации состояний, нежели писать код.

Если же вы пишете простые прикладные вещи, которым нужно показать какую-то графику, то учите OpenGL. Здесь вы учите только API, соглашаясь с уже готовым, слегка устаревшим, архитектурным дизайном.

Если хотите писать игры не мирового класса, то учите готовые движки, Unity или Unreal. Они уже поддерживают за вас Vulkan, продумали за вас API и архитектуру.

Для того, чтобы ArrayList знал, какие объекты в нем хранятся, нужно указать их класс явно:
ArrayList<String> list = new ArrayList<>();
Тогда list.get(i) будет возвращать String и желаемый код заработает.

Запись же
ArrayList list = new ArrayList()
эквивалентна записи
ArrayList<Object> list = new ArrayList<>()
В таком случае, list.get(i) возвращает не String, а Object, у которого метода length() просто не существует

Зависит от типа массива. Для массива байтов, например - это [B. Для массива строк - [Ljava.lang.String.

Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова… Пользователь может играть лесными эльфами, охраной дворца и злодеем. И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы…

Делаем много мешей (планета в форме шара, игрока и прочее), добавляем им примерно такой скрипт:

class Gravity : MonoBehaviou {
    static const double G = 9.8; // correct constant here

    static LinkedList<Gravity> meshes = new LinkedList<Gravity>();

    float Mass {
        get {
            return GetComponent<Rigidbody>().mass;
        }
    }

    void Start() {
        meshes.add(this);
    }

    void Update() {
        foreach(var mesh in meshes) {
            float power = (float)(G*Mass*mesh.mass);
            var force = power*(mesh.transform.position - transform.position).normalized;
            force /= (mesh.transform.position - transform.position).sqrMagnitude;
            GetComponent<Rigidbody>().AddForce(force);
        }
    }
}

Горизонтальность оставим в качестве домашнего задания. Подсказка - нужно повернуть меш игрока так, чтобы он был сонаправлен с вектором земля-игрок.

Есть разные варианты. Я, например, использую следующий подход:
1. Есть view, которая не знает ни о чем. Умеет только показывать данные. Обычно имеет интерфейс описывающий все свойства, которые можно отобразить в этой view.
2. Есть presenter, который знает о IView(интерфейсе view) и использует его, чтобы передать данные для отображения.
3. Обратная передача информации, т.е. реакция на что-то что происходит на форме осуществляется через события. Т.е. view кидает событие и ей без разницы, кто его поймает. Presenter следит за событиями и что-то делает с моделью, а потом передает новые данные через интерфейс обратно во view, если нужно.

Что касается точки входа, то в моем варианте создается view и presenter,которому эта view передается. view кладется на форму и все. Когда view передали presenter'у он ее заполнил данными и подписался на события.

99% что запускаете в UI-потоке.
В логе должен быть эксепшн что так делать нельзя.
Все операции с сетью делаются только в параллельном потоке. Мануалы в гугле есть, полно.

начнем с того, что *100# - это вообще не смс. это USSD

Вот тут все написано: https://developer.android.com/ndk/guides/index.html

isEditable()

retrolambda и импортозамещение streamapi можно уже давно делать и писать в стиле java8 под андроид

Может ли модифицирующий метод возвращать что-нибудь кроме типа void

может. см. "method chaining", "fluent api" и пр.