Android uses SQLite, rather than SQL.  What's the difference?

SQL:  Is this very complex thang.  SQL runs a server on your machine.  Individual processes communicate with this server to access and modify databases.  This is because there may be multiple processes accessing these databases and you don't want these processes interfering wiht each other.

SQLite:  Doesn't have the bureaucracy.  Working on the principle that only one app is ever going to access a certain database, it doesn't need a server, it doesn't need to lock anybody out.  There's one process and SQLite is the interface that lets it directly access and modify the database.

The SQL commands are the same.  The difference is the implementation.

So, within an Android app, you can use the SQLite to create from scratch brand new SQLite databases.  But that's the hard way.

The easiest way is to create a database, possibly empty, possibly seeded with stuff, in advance, and load that database into the "assets" folder while you are writing the app, so that the app BEGINS with a database already created and possibly already containing stuff.

Free software that will do this for you is called "DB Browser For SQLite"

MOVIES

TITLE GENRE YEAR DESCIPTION id

A database can contain any number of interrelated tables.  It's not unusual to have hundreds of tables in a database system.  We probably won't use more than two.

A table contains a list of records, and each record is broken up into fields.  Our MOVIES table contains fields for TITLE GENRE YEAR DESCRIPTION id (id is autogenerated.  We'll add the rest of the stuff ourself.)

The primary key is the main thing the database is indexed by.

Autoincrement means when a record is added, it's primary key (id) is one higher than the last one that was created.